In-depth understanding of Java Virtual Machine Learning notes 9--concurrent programming (i)

With the rapid development of multi-core CPU, in order to make full use of the computing resources of hardware, the concurrent multitasking function of the operating system is becoming more and more important, but the CPU also needs to read the output from memory and store the result in memory, but because the CPU is more than a few orders of magnitude higher than memory, The number of registers and the capacity of the CPU is limited, in order not to allow the CPU to wait for a long time in memory idle state, between the CPU and memory introduced a speed close to the CPU cache caches as a buffer between the CPU and memory. The principle of computer hardware concurrency is as follows:

Java Virtual machine support for concurrency is similar to computer hardware, and the concurrency support for Java virtual machines is implemented through the memory model of the Java Virtual machine. The memory model of the Java Virtual machine is divided into primary memory and working memory, all the variables in the program are stored in main memory, each thread has its own private working memory, the working memory holds the main memory copy of the variables used by the thread, and all the operations of the thread to the variable (read, assign, etc.) must be in working memory. Instead of directly reading and writing the variables in the main memory, there is no direct access to the variables in the working memory of the other threads, and the transfer of variable values between the threads needs to be done through main memory. The Java Virtual machine concurrency principle is as follows:

The Java Virtual machine memory model defines 8 interactive protocol operations on main memory and working memory:

(1). Lock Lock: A variable that acts on the main memory and identifies 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 freed variable can be locked by another thread.

(3). Read read: A variable that acts on the main, transferring the value of a variable from main memory to the working memory of the thread for subsequent load actions to use.

(4). Load load: A variable that acts on a working memory and puts the value of a read read operation from the 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 Java Virtual Machine execution engine, which is executed whenever the virtual opportunity is to a bytecode instruction that needs to use the value of the variable.

(6). Assign assignment: Acts on the working memory variable, assigns a value of a variable received from the execution engine to the work variable, which is performed whenever the virtual opportunity is to a byte code assigned to a variable.

(7). Store Store: A variable that acts on the working memory, transferring 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, putting the store operation from the value of the variable obtained in the working memory into the variable of the main memory.

The Java memory model has the following constraints on the above 8 operations:

(1). Copying a variable from main memory to working memory must perform read read-in operations and load loading operations sequentially.

Synchronizing a variable from the working memory back into main memory must be performed in the Order of store operations and write writes.

Other directives can be inserted between the read and load operations, between the store and the write operation, but the read and load operations, store, and write operations must be executed sequentially, that is, one of the read and load, store, and write operations is not allowed to appear separately.

(2). A thread is not allowed to discard its most recent assign assignment operation, which means that the value of the working memory variable must be synchronized back to main memory after it has changed. Only variables that have undergone assign assignment operations need to be synchronized from the working memory back to main memory.

(3). A new variable can only be generated in main memory, and it is not allowed to use a variable that is not initialized (load or assign) directly in working memory, that is, a variable must perform the Assgin and load operations before performing a use and store operation.

(4). A variable allows only one thread to lock a lock on it at the same time, but the lock lock can be repeated multiple times by a thread, and after the lock is executed multiple times, only the unlock action variable that executes the same number of times is unlocked.

(5). If a lock lock operation is performed on a variable, the value of the 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.

(6). If a variable is not locked by lock in advance, the variable is not allowed to be unlock unlocked, and a variable locked by another thread is not allowed to be unlock unlocked.

(7). Before a variable can be unlock unlocked, this variable must be synchronized back to main memory (performing store and write operations).

Keyword volatile in Java is the most lightweight thread synchronization mechanism provided by a Java virtual machine, and when a variable is declared volatile, the variable will have the following two features:

(1). The volatile guarantee variable is visible to all threads, that is, after any one thread modifies the value of the variable, the new value is immediately known to all other threads.

Instead, the normal variable needs to synchronize the variables in the working memory back into main memory, and the other threads need to reread the values of the variables from the main memory to use the most recent modified values.

Volatile variables can also be inconsistent in each working memory, but since each use needs to be refreshed (working memory variables re-initialized), the execution engine does not see variable inconsistencies, so there is no inconsistency in task volatile variables.

But the operations in Java are not all atomic operations, so it is not safe for volatile variables to run in parallel.

Because volatile variables can only guarantee visibility, thread safety is only possible if the following two rules are met.

A. The result of the operation does not depend on the current value of the variable, or can ensure that only a single thread modifies the value of the variable.

B. Variables do not need to participate in invariant constraints with other variables.

In the case of non-conformance with the two rules above, thread safety still needs to be ensured by synchronized synchronization keyword or locking mechanism.

(2). Volatile prohibit command reordering optimization.

The normal variable can only guarantee that the correct result can be obtained in all the places where the result of the assignment is dependent on the execution of the method, and the order of variable assignment is not guaranteed to be consistent with the execution order of the program code.

The volatile prohibit command reordering, so the volatile variable is constrained as follows:

The operation of the A.volatile variable must be in Read->load->use order, that is, each time you use a variable in your working memory, you must first refresh the latest value from main memory to ensure that you can see the latest modifications to the variable by other threads.

B. The action of the volatile variable must be in Assign->store->write order, that is, the value of the variable must be synchronized back to main memory each time the working memory is assigned a value, to ensure that other threads can see the latest modification of the variable.

C. If a thread assign or use a volatile variable A is preceded by a assign or use operation on the volatile variable B, the thread is read/load or store/to the volatile variable A. The write operation must precede the read/load or store/write operation on volatile variable B.

(EXT) "In-depth understanding of Java Virtual Machine" Learning note 9--concurrent programming (i)