Network Security Internet Technology Development Database Servers Mobile Phone Android Software Apple Software Computer Software News IT Information

In addition to Weibo, there is also WeChat

Please pay attention

WeChat public account

Shulou

Example Analysis of memory Model JMM in Java

2025-02-24 Update From: SLTechnology News&Howtos shulou NAV: SLTechnology News&Howtos > Development >

Share

Shulou(Shulou.com)06/03 Report--

Editor to share with you the example analysis of the memory model JMM in Java, I believe that most people do not know much about it, so share this article for your reference, I hope you can learn a lot after reading this article, let's go to know it!

Sometimes the optimization of the compiler and processor will cause the runtime to be different from what we imagined, so Java imposes some restrictions on the compiler and processor, which are abstracted by the JAVA memory model (JMM), so that you don't have to consider so many underlying details when writing code, and guarantee that "as long as you follow the rules of JMM, the results must be correct."

Abstract structure of JMM

In Java, all instances and static variables are stored in heap memory, and heap memory can be shared between threads, which is also called shared variables. The local variables, method definition parameters and exception handling parameters are in the stack, and the stack memory is not shared between threads.

However, the optimization of compiler and processor will lead to visibility problems of shared variables, such as in multi-core processors (multi-processor), threads can execute on different processors, while inconsistent caches between processors will cause visibility problems of shared variables, and it is possible for two threads to see different values of the same variable.

JMM abstracts these hardware optimizations into the idea that each thread has a local memory. When you need to read and write shared variables, copy a copy from main memory to local memory. When writing shared variables, write to local memory first, and then refresh to main memory at some point in the future. When the shared variable is read again, it is only read from local memory.

In this way, communication between threads takes two steps:

Write thread: refresh local memory to main memory to read thread: read updated value from main memory

There is a delay between write and read: when will the local memory be flushed to the main memory? As a result of visibility problems, different threads may see different shared variables.

Happens-before

Happens-before literally means "before that". This is the rule made by java for the order of program execution, which must be followed to achieve synchronization. In this way, programmers only need to write the correct synchronization program, and happens-before ensures that the results will not be wrong.

A happens-before B not only means that An executes before B, but also means that the execution result of An is visible to B, which ensures visibility.

A happens-before BMague A does not have to be executed before B. if the AB alternates and the execution result is still correct, the compiler and processor are allowed to reorder optimally. So as long as the program results are correct, no matter how the compiler and processor are optimized or reordered, they are all good.

Happens-before rule

Program order rule: in a thread, the operation lock rule after the previous operation happens-before: unlock happens-before and lock volatile domain rule: write volatile variable, any one after happens-before reads the operation transitivity of this volatile variable: a happens-before Bjinger B happens-before C Then A happens-before C start () rule: if thread An executes ThreadB.start (), then any operation join () in ThreadB.start () happens-before thread B rule: if thread An executes ThreadB.join (), then all operations in thread B happens-before ThreadB.join ()

The following example helps to understand happens-before

Double pi = 3.14; / / Adouble r = 1.0; / / Bdouble area = pi * r * r; / / C

There are three happens-before relations. Rules 1 and 2 are program order rules, and rule 3 is derived from transitive rules:

A happens-before B B happens-before C A happens-before C

C depends on An and B, but neither A nor B. So even if An and B reorder, the execution result will not change, this kind of reordering, JMM is running.

The results of the following two execution orders are correct.

The above is all the contents of the article "sample Analysis of the memory Model JMM in Java". Thank you for reading! I believe we all have a certain understanding, hope to share the content to help you, if you want to learn more knowledge, welcome to follow the industry information channel!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.

Views: 0

*The comments in the above article only represent the author's personal views and do not represent the views and positions of this website. If you have more insights, please feel free to contribute and share.

Share To

Development

Wechat

© 2024 shulou.com SLNews company. All rights reserved.

12
Report