Explain the Java memory model in a simple way

Interviewer : I remember asking why there is a Java memory model last time

Interviewer : I remember your final answer is: In order to shield the various differences between hardware and operating system access to memory, Java proposed the "Java Memory Model" specification, which ensures that Java programs can access memory under various platforms Can get consistent results

candidate : Well, that's right

Interviewer : Or else, you will talk about the Java memory model today?

candidate : Well, before I talk about it, I still have to emphasize: the Java memory model is a "standard", and the Java virtual machine implements this standard.

candidate : The main content of the Java memory model, I personally think there are the following

candidate : 1. Abstract structure of Java memory model

candidate : 2. Happen-before rule

candidate : 3. Discussion on the semantics of volatile memory (I will explain this later)

Interviewer : Then how about you start from the first point? Let's talk about the abstract structure of the Java memory model first?

candidate : Hmm. The Java memory model defines: the specification for Java threads to interact with memory data.

candidate : The "shared variables" between threads are stored in the "main memory", each thread has its own private "local memory", and the "local memory" stores a copy of the thread to read/write shared variables .

candidate : Local memory is an abstract concept of the Java memory model, not real.

candidate : by the way, draw a picture, you will understand after reading the picture.

candidate : The Java memory model stipulates that all operations on variables by threads must be performed in "local memory", and variables in "main memory cannot be directly read and written"

candidate : The Java memory model defines 8 operations to complete "how variables go from main memory to local memory, and how variables go from local memory to main memory"

candidate : read/load/use/assign/store/write/lock/unlock operations respectively

candidate : Seeing that there are a lot of 8 operations, these operations are covered by one reading and writing of variables. I will draw another picture to tell you about it.

candidate : Understood? It is nothing more than reading and writing using various operations (:

Interviewer : Understand, it's very simple, what is happen-before next?

candidate : Well, good (:

candidate : According to my understanding, happen-before is actually a set of "rules". The Java memory model defines this set of rules, the purpose is to explain the "visibility" of the memory "between operations"

candidate : Since the last time I talked about "instruction rearrangement", I mentioned that there are problems with instruction rearrangement at the CPU and compiler levels.

candidate : Although instruction rearrangement can improve the efficiency of operation, in concurrent programming, we also hope that the "program result" can be controlled by us while taking into account "efficiency".

candidate : To put it bluntly: in some important scenarios, this set of operations cannot be reordered, "the result of the previous operation must be visible to subsequent operations."

Interviewer : Well...

candidate : So, the Java memory model puts forward the happen-before set of rules, there are a total of 8 rules

candidate : such as transitivity, volatile variable rules, program sequence rules, monitor lock rules... (see the meaning of the rules in detail, this is not difficult)

Candidate : Just remember, with the happen-before rules. As long as the code we write is under these rules, the result of the previous operation is visible to subsequent operations, and reordering will not occur.

Interviewer : I understand what you mean

Interviewer : about volatile?

candidate : Well, volatile is a keyword in Java

Candidate : Why is the keyword volatile often mentioned when talking about the Java memory model? I think it is mainly due to its characteristics: visibility and ordering (reordering is prohibited)

Candidate : The Java memory model specification, to a large extent, is to solve the problem of visibility and order.

Interviewer : Then you can talk about its principle, how does the keyword volatile achieve visibility and order

Candidate : In order to achieve volatile orderliness and visibility, the Java memory model defines 4 "standards" of memory barriers, namely LoadLoad/LoadStore/StoreLoad/StoreStore

candidate : Going back to volatile, to put it bluntly, it is to add a "memory barrier" before and after volatile, so that the compiler and CPU cannot reorder, resulting in order, and writing volatile variables is visible to other threads.

candidate : Java memory model defines the specification, then the Java virtual machine must be implemented, right?

Interviewer : Well...

Candidate : I have seen the implementation of the Hotspot virtual machine before. At the "assembly" level, it is actually implemented by the Lock prefix instruction instead of various fence instructions (the main reason is simplicity. Because most platforms support the lock instruction , And the fence instruction is for the x86 platform).

candidate : The lock instruction can guarantee: prohibit the reordering of the CPU and the compiler (to ensure order), ensure that the CPU write core instructions can take effect immediately, and the cache data of other cores are invalid (to ensure visibility).

Interviewer : Then you mentioned this, I want to ask what is the relationship between volatile and the MESI protocol?

Candidate : They are not directly related.

Candidate : The Java memory model focuses on the programming language level, which is a high-dimensional abstraction. MESI is a CPU cache coherency protocol. Different CPU architectures are different. Some CPUs may not use MESI protocol at all...

Candidate : It's just that MESI is famous, so everyone has taken him as an example. And MESI may only be a part of "in a specific scenario" that is used to achieve the visibility/ordering of volatile (:

Interviewer : Well...

Candidate : In order to allow Java programmers to shield the above low-level knowledge, quickly get started using volatile variables

candidate : There is a definition of the volatile variable rule in the happen-before rule of the Java memory model

candidate : The content of this rule is actually: the write operation to a volatile variable is visible to the subsequent read operation to the volatile variable

candidate : It is stipulated by the happen-before rule: As long as the variable declares the volatile keyword, it is read after writing, and the value written must be visible when reading. (Visibility, orderliness)

Interviewer : Well... I understand

This article summarizes :

• Why does the Java memory model : In order to shield the various differences between hardware and operating system access to memory, Java has proposed the "Java Memory Model" specification to ensure that Java programs can access memory under various platforms to achieve consistent results
• Java memory model abstract structure : "Shared variables" between threads are stored in "main memory", each thread has its own private "local memory", "local memory" stores the thread for read/write sharing A copy of the variable. All operations of threads on variables must be performed in "local memory", and variables in "main memory cannot be directly read and written"
• happen-before rule : The Java memory model stipulates that in certain scenarios (a total of 8 items), the result of the previous operation must be visible to subsequent operations. These 8 rules become happen-before rules
• volatile : Volatile is a keyword of Java, and the modified variables are visible and ordered (will not be reordered). Visibility is completed by the happen-before rule, and order is completed by the "memory barrier" defined by the Java memory model. The actual HotSpot virtual machine implements the Java memory model specification, and the assembly bottom layer is implemented through the Lock instruction.

Welcome to follow my WeChat public [16178a4a030362 Java3y ] to talk about Java interviews, the online interviewer series is being updated continuously!

[Online Interviewer-Mobile] The series updated twice a week!

[Online Interviewer-Computer Terminal] The series updated twice a week!

Originality is not easy! ! Seek three links! !