Java concurrency Programming 17: Drill down into the Java memory Model-summary of memory operations rules

main memory vs. working memory

The main goal of the Java memory model is to define the access rules for each variable in the program, that is, the underlying details of storing variables in the virtual machine into memory and removing variables from memory. The variables here are mainly shared variables, and there are competition problems. the Java memory model stipulates that all variables are stored in main memory, and that each thread has its own working memory, that the thread's working memory holds a copy of the master memory of the variable used by the thread, and that all operations of the thread on the variable (read, assign, and so on) must be in working memory. Instead of directly reading and writing the variables in the main memory ( according to the Java Virtual Machine specification, the volatile variable still has a copy of the shared memory, but due to its special sequence of operations-the data must be synchronized to the working memory before reading and writing from the working memory. All look like read-write access directly in main memory, so the description here is no exception to volatile . There is no direct access to variables in the other's working memory between different threads, and the variables worth passing between threads need to be done through main memory.

Inter-memory interaction operations
The following 8 operations are defined in the Java memory model to complete the implementation details of the interaction between main memory and working memory:

1. Luck (lock): A variable that acts on the main memory, which marks a variable as a thread-exclusive state.

2. Unlock (unlock): A variable that acts on the main memory, releasing a variable that is in a locked state, and the released variable can be locked by another thread.

3. READ: A variable acting on the main memory, which transfers the value of a variable from main memory to working memory for subsequent load actions.

4. Load (load): A variable that acts on the working memory, which puts the value of the variable that the read operation obtains from main memory into a variable copy of the working memory.

5. Use: A variable acting on a working memory that passes the value of a variable in the working memory to the execution engine, which is performed whenever the virtual opportunity is a worthwhile bytecode instruction that needs to be used to a variable.

6, assign (Assignment): A variable acting on the working memory, which assigns a value received from the execution engine to the working memory variable, which is performed whenever the virtual opportunity is assigned to a byte-code instruction that assigns a variable value.

7. Store: A variable acting on a working memory that passes the value of a variable in the working memory to the main memory for subsequent write operations to use.

8. Write (write): A variable that acts on the main memory, which puts the value of the store operation from the working memory into the variable of the main memory.

the Java memory model also stipulates that the following rules must be met when performing the 8 basic operations described above:

1. Does not allow one of the read and load, store, and write operations to appear separately, the above two operations must be executed sequentially, but there is no guarantee that continuous execution is required, that is, between read and load, between store and write can be inserted into other directives.

2. A thread is not allowed to discard its most recent assign operation, that is, the variable must be synchronized back to main memory after it has changed in working memory.

3. One thread is not allowed to synchronize data from the working memory of the thread back to main memory for no reason (no assign operation has occurred).

4, a new variable can only be "born" from the main memory, not allowed in working memory directly using a non-initialized (load or assign) variable, in other words, the use and store operation for a variable must be performed before the assign and load operations.

5. A variable is allowed only one thread to perform a lock operation on it at the same time, but the lock operation can be repeated multiple times with the same thread, and after the lock is executed multiple times, the variable will be unlocked only if the same number of unlock operations are performed.

6. If a lock operation is performed on a variable, the value of this variable in the working memory will be emptied, and the value of the variable initialized by the load or assign operation needs to be re-executed before the execution engine uses the variable.

7, if a variable implementation is not locked by the lock operation, it is not allowed to perform unlock operations on it, nor allow to unlock a variable locked by another thread.

8. Before performing a unlock operation on a variable, you must first synchronize this variable back to main memory (perform store and write operations).

special rules for volatile variable types
The Java memory model specifically defines some special access rules for volatile, and when a variable is defined as volatile, he will have two features:

1. Ensure the visibility of this variable to all threads. This is not explained in detail here. Note that the write operation of the volatile variable is visible in addition to its own read operation, and all shared variables prior to the volatile write operation can be seen after the volatile read operation, in addition to the applicable scenarios, see http:// blog.csdn.net/ns_code/article/details/17290021 and http://blog.csdn.net/ns_code/article/details/17101369 this two blog post.

2, prohibit command reordering optimization. Ordinary variables only guarantee that the correct results will be obtained in the execution of the method, with all dependent on the result of the assignment, without guaranteeing that the order of the variable assignment is consistent with the order of execution in the program, which we cannot perceive in a single thread.

Supplement:theJava language Specification specifies that sequential semantics are maintained internally within the JVM thread, meaning that the order of execution of the instructions may not be consistent with the order of the Code as long as the final result of the program equals its results in a strictly sequenced environment. This process is done by reordering called directives. The meaning of command reordering is that the JVM is able to properly reorder machine instructions based on the characteristics of the processor (multi-level cache system, multi-core processor, etc.), so that the machine instruction is more consistent with the performance of the CPU, and the machine is maximized. In the absence of synchronization, the compiler, the processor, and the runtime may make some unexpected adjustments to the execution order of the operation

final FieldIn addition to this, the final domain has special semantics in the Java memory model, and the final domain ensures the security of the initialization process, allowing unrestricted access to immutable objects and no synchronization when sharing those objects. Specifically, the final modified field is initialized once in the constructor, and the constructor does not pass a reference to "this" (the This reference escapes is a very dangerous thing, other threads may access the "initialized half" object through this reference), The value of the final field can be seen in other threads, and the externally visible state will never change. The security that it brings is the simplest and purest.

special rules for long and double variables
the Java memory model requires that the 8 operations of lock, unlock, read, load, assign, use, store, and write are atomic, but for 64-bit data types long and double, A loose rule is defined in the model that allows the virtual machine to divide the read and write operations of 64-bit data that are not volatile-modified into two 32-bit operations. Thus, if there are multiple threads sharing a long or double type of variable that is not declared volatile, and both are read and modified, some threads may read a value that is neither the original nor the other thread to modify the value that is worth representing the "half-variable". This is very rare, however, because the Java memory model allows the virtual machine not to implement the long and double variable reads and writes into atomic operations, but allows the fast choice to implement these operations as atomic and "strongly recommend" virtual machines to do so. At present, the commercial virtual machines under various platforms are almost all selected. Read and write operations for 64-bit data are treated as atomic operations, so it is not necessary to specifically declare long and double variables as volatile when encoding.

Reference:http://blog.csdn.net/vking_wang/article/details/8574376#t2

"In-depth understanding of Java Virtual Machine--JVM advanced features and Best practices" chapter 12th

Java concurrency Programming 17: Drill down into the Java memory Model-summary of memory operations rules