JDK source code reading-Java Memory Model

JDK source code reading-Java Memory Model
0. Why the Java memory model is required?
In order for programmers to ignore the memory access differences between various hardware and operating systems, there is no need to worry about the differences between memory models in different architectures, java provides a Java memory model between the code and Hardware Memory models.

I. Concurrent model classification
In concurrent programming, two key issues need to be dealt with: how to communicate between threads (there are two ways to exchange information between threads: Shared Memory and message transmission) and how to synchronize between threads.
In the concurrency model of shared memory (such as Java), the common states of programs are shared between threads, and between threads are implicitly (transparent to programmers) through the public states in the write-Read Memory (primary memory) communication. In the message transmission concurrency model, there is no public state between threads, and the threads must explicitly send messages for explicit communication.
Synchronization refers to the mechanism by which a program is used to control the relative sequence of operations between different threads. In the shared memory concurrency model, synchronization is performed explicitly. The programmer must explicitly specify a method or code segment to be mutually exclusive between threads. In the message transmission concurrency model, because the message must be sent before receiving the message, the synchronization is implemented implicitly.
Although Java is a shared-memory concurrency model that is transparent to programmers, if you do not understand the Java memory model, you cannot find a solution to problems such as memory visibility and orderliness.


2. Data zone during Java virtual machine running

The VM Stack describes the Memory Model of Java execution: each method creates a Stack Frame while executing it) stores information about local variable tables, operand stacks, dynamic links, and method exits.
The main objective of the Java memory model is to define the access rules for various variables in the program, including the read and write operations on the variables in the virtual machine, the lock and release operations on the monitor, as well as the thread startup and merge operations.


Iii. atomicity, visibility, and orderliness
The Java memory model is built around how to handle atomicity, visibility, and orderliness in the concurrent process.
Atomicity: The operation cannot be further divided. For example, synchronized and ReentrantLock are used in Java code. Visibility: A thread operation, visible to thread B. It can be seen that the value of A variable is 1, and that of thread B has changed to 1. Synchronized, final, volatile, and ReentrantLock are both available. Orderliness: observed in this thread, all operations are ordered (represented by serial semantics in the thread); if you observe another thread in another thread, all operations are unordered (Command Re-sorting and synchronization delay between the working memory and the main memory ). Synchronized, volatile, and ReentrantLock can guarantee orderliness. We can see from the above that synchronized and ReentrantLock are omnipotent, but there is a huge difference in efficiency. ReentrantLock will be much better than synchronized, the source code implementation of ConcurrentHashMap uses the ReentrantLock to improve concurrency security and efficiency.


Iv. Happens-Before rules
To ensure that thread A sees the operation result of thread B (whether or not A and B are executed in the same thread), the relationship between A and B must satisfy the Happens-Before relationship. The Happens-Before rules are as follows:
Program Order Rule: if operation A in A Program is prior to operation B, the process A operation will be performed before operation B.
Monitor Lock Rule: the lock operation for the same Lock after an unlock operation happen-before (the order of time, the same below.
Volatile variable rules: Read operations on a volatile variable after the write operation happen-before.
Thread startup rules: the start () method of the Thread object happen-before each action of this Thread.
Thread termination rules: all operations of a Thread are detected by happen-before. join () method end, Thread. isAlive () return value and other means to detect that the thread has terminated the execution.
Thread interruption rules: Call the thread interrupt () method happen-before occurs when the code of the interrupted thread detects the occurrence of the interrupted current event.
Finalizer Rule: the initialization of an object (the execution of the constructor ends) The start of the happen-before method.
Passability: If you operate A happen-before to operate B and B happen-before to operate C, you can obtain A happen-before to operate C.
If there is no Happens-Before relationship between the two operations, the JVM can sort them as needed.