Deep Java memory model (i)

Recently, I wanted to learn more about Java threads, and I wanted to know how to implement them, such as thread sharing, thread-private space, and thread-direct synchronization control. If you can understand its implementation, it will be of great help to learn the thread deeply. I'm looking at a piece of information about the deep Java memory model. This is the Java Threading Implementation principle, take out to share.

When it comes to threading, the first thing we think about is thread communication. When learning the operating system, there are two types of thread communication, one is through shared memory and the other through message delivery. Shared memory is implicit communication, where threads share a piece of memory, and threads can write data to this block of memory, and read the data to achieve communication. While message passing is a display process where you want to communicate to another thread, you must send it a message and another thread accepts the message. This also enables a communication. One of the important functions in a thread is synchronization. For shared memory, because their communication is implicit, synchronization must be explicitly indicated by the synchronization action. For message delivery, the send is definitely in front of the acceptance, which belongs to implicit. So what exactly does Java thread belong to? If we know something about the type of memory in Java, we should know that we are using shared memory mode.

We analyze Java's memory classification in terms of threading. The most common, and the most we use is the stack and heap. Simply put, the stack belongs to the Java thread's private memory and cannot be accessed between threads. While the heap is shared memory, the data can be shared between threads through the heap. As shown in the following:

This diagram illustrates the relationship between Java threads and the Java memory model.   Reorder: Reordering This is useful in many places. such as processor processing of instructions, database system to the processing of concurrent data. In executing the program, the Java compiler and the processor will reorder the instructions, for example, a series of actions, 1, read a,2, read b,3, write a,4, write B. Then the processing time, may become, 1,3,2,4 order, we know that this execution and the original order of execution results are the same, But it will be more efficient. Java's various compilers have their own reordering capabilities to maximize efficiency. For a single thread, reordering does not have any problem.　　But for multithreading, this sort is likely to disrupt the program's results.　　　　Reordering consists of three types: one is a reordering of the execution order by the Java compiler.　　　　The second is a reordering of the order of instructions executed by the processor.　　Three is the memory system, because the use of cache and read-write cache, so that loading and execution may cause disorderly execution. The end result is a reordering of execution instructions.　　　　　　　  We use the following code to illustrate: code 1:{int a = 1;  //step A1 int y = b;//Step A2} code 2:{int b = 1;//step B1 int x = a;//Step B2} Two threads execute code 1, code 2, respectively. The result we expect is y= 1,x = 2. But the reality is that it may make the x=y=0; if you don't know about reordering, you won't see this result. So how does the reordering work? Because the two steps in the code are irrelevant, the order of execution can be executed for a2,b2,a1,b1 so that a, a, a, A/b initial value is 0, and natural x, Y is 0. From this we can see that the reordering function makes it not clear what the end result will be, if that is certainly unreasonable. The   JVM certainly has a certain specification for this. The first reordering should not change the result of the execution. First, the data dependencies cannot be sorted.　　What is data dependency?　　For example {y = a A = 5} The order of the two can not be changed, they depend on the data of a, the change will affect the result. reordering conforms to the principle of data dependency, and if he executes in the order in which the code is written, it must be fine. The same question just now. Execution order A1,A2. The execution order of the B1,B2 is unchanged. It is still possible to get the x= y= 0 case. For what reason? This is related to the Java threading model. Java Line threads private memory and shared memory。 Step A1, write A= 1, the first thing to do is just 1 write to the private memory of the temporary variable, put in write buffer. Take the second step at the same time, read B. In code 2, too, the b=2 is not actually written in shared memory, but also in write buffers. This reads the shared memory B or 0, and then writes the write buffer to the shared memory. The process is as follows: For this scenario, the JVM has a memory barrier mechanism that can effectively control the execution of the program in its own way. The memory barrier is the order that controls the loading and writing of data. There are four types of memory barriers to the JVM:  1,loadload, such as Load1 loadload load2, to ensure that load1 data is loaded before load2 and subsequent load instructions  2,storestore, such as Store1 Storestore Store2 to ensure that store1 data is visible to other processors and threads (flushed to memory) prior to Store2 and subsequent storage instructions.  3,loadstore, such as Load1 Loadstore Store1, ensures that load1 data is flushed to memory before it is loaded in Store1 and later.  4,storeload such as Store1 storeload load1 ensure that the Store1 data is visible to other threads of other processors (flushed to memory) before the LOAD1 and subsequent data load instructions. The memory access instruction after the barrier is executed before the memory instruction (load and store) is executed.  JVM has these four memory barriers to effectively control the reordering. But this understanding and use is more troublesome. jdk1.5 the memory model used later, using a happen-before probability to illustrate the direct memory visibility of the operation. So that it doesn't need to focus on memory barriers. The main happen-before rules are as follows: 1, for a single thread: each operation in the middle Happen-before each subsequent operation (for this, not the order of execution, which is the visible result of execution.) If none of the two instructions are relevant.　　Then the visible result of execution is the same, it does not necessarily follow the order of execution) 2, the monitor operation: The unlock of the monitor is happen-before to the subsequent locking of this monitor. 3, for volatile variables, write happen-before with subsequent reads.　　(Here the write and read, refers to the shared memory, not the private memory) 4, transitivity, if a happen-before b,b happen-before C, then a Happen-before c. For Happen-before in JVM as well as reordering direct relationships like:  above are a holistic introduction to the Java memory model, which hopefully will deepen the understanding of Java memory models through subsequent learning.  

Drill down into the Java memory Model (i)