JVM series (7) - java memory model

1. What is JMM

An abstract specification. The implementation of each JVM must abide by such specifications, so as to ensure that Java programs can be "written once and run everywhere".
The memory model describes the relationship between various variables (instance fields, static fields, and array elements) in the program, as well as the low-level details of storing variables into memory and fetching them from memory in actual computer systems .

Two, JMM structure

1. CPU cache model

Directly above:
insert image description here
"In-depth understanding of high-concurrency programming" Chapter 6.1.2 CPU multi-level cache architecture principle.
ps: The blocked word is that the main memory in the computer is accessible to all CPUs, and the capacity of the main memory is larger than the CPU cache.
insert image description here
Image source: https://github.com/Snailclimb/JavaGuide/issues/1848
Explain:
When the computer executes the program, each instruction is executed in the CPU. In the process of executing instructions, reading and writing of data is bound to be involved.
The temporary data during program running is stored in the main memory (physical memory). At this time, when reading and writing data, the CPU processing speed is much faster than the memory processing speed! The two are completely inconsistent.
The working method of the CPU cache model: first copy a copy of data to the CPU Cache, when the CPU needs to use it, you can directly read the data from the CPU Cache, and when the operation is completed, write the obtained data back to the Main Memory. However, there is still the problem of memory cache data inconsistency. At this time, this problem can be solved by formulating a cache consistency protocol (such as the MESI protocol).

2. JMM model

insert image description here
The picture comes from my other blog: Multithreading and high concurrency (2) - detailed
explanation of synchronized usage. Explain:
From an abstract point of view, JMM defines the abstract relationship between threads and main memory: shared variables between threads are stored in main memory (main memory), and each thread has a private local memory (local memory), which stores a copy of the thread to read/write shared variables. Local memory is an abstract concept of JMM and does not really exist.
Main memory : The instance objects created by all threads are stored in the main memory, regardless of whether the instance object is a member variable or a local variable in a method (also called a local variable
) . Local memory is a concept abstracted by JMM, which stores a copy of shared variables in main memory. For example, X=0, thread 1 is changed to X=1, then it needs to be synchronized to the main memory, and the main memory is then given to thread 2, which is the visibility
between threads . However, for the three major characteristics of JMM: atomicity, visibility, and orderliness , you can refer to Multithreading and High Concurrency (2) - Detailed Explanation of Synchronized Usage .

3. Out-of-order execution && prohibit out-of-order

The following content can be referred to:
Multithreading and high concurrency (2) - detailed explanation of synchronized usage .
Multithreading and high concurrency (5) - volatile keyword detailed explanation of
multithreading and high concurrency (3) - synchronized principle

1. Out-of-order execution

In order to improve the execution efficiency of the cpu, when the a instruction is doing other things, let the b instruction execute.
It has to be mentioned that instruction reordering. The order of variable assignment operations is inconsistent with the execution order in the program code.
In order to prevent out-of-order execution, how to regulate the JVM level?
Similar to CPU memory barriers, JVM also defines memory barriers.
insert image description here

2. volatile prohibits out-of-order implementation details

(1) The ACC_VOLATILE identifier at the bytecode level
.
(2) JVM level
When writing, add the SS instruction in front and the SL instruction in the back;
when reading, add the LL instruction in front and the LS instruction in the back.
(3) OS and hardware level
lock instructions.

3. Synchronized prohibits out-of-order implementation details

(1) ACC_SYNCHRONIZED identifiers, monitorenter and monitorexit identifiers at the bytecode level
.
(2) At the JVM level,
c/c++ calls the synchronization mechanism provided by the operating system.
(3) OS and hardware level
lock instructions.

Guess you like

Origin blog.csdn.net/liwangcuihua/article/details/131786794