Java Memory Model
Java Virtual Machine specification defines the Java Memory Model (Java Memory Model, JMM)
JMM main objective is to define access rules in the program of the variables, i.e. stored in memory and removed from memory variable in the virtual machine in the variable. ( Variables include: instance fields, static fields and array elements constituting the object, the method does not include local variables and parameters, as the latter is private, not shared, there is no problem of competition )
JMM provides all the variables are stored in the main memory (Main Memory) , each thread also has its own working memory (Working Memory), working memory thread is saved in the main memory copy is to use the thread to the variable. Thread all operations on variables (reading, assignments, etc.) must be in working memory, but can not directly read and write the main variables in memory. Between different threads can not directly access the working memory of the other variables, the variable value passed between threads are required to complete the main memory.
Main memory object instance corresponding to the main data portion in the Java heap, the working memory area of the virtual machine part corresponds stack .
Between the main memory and working memory interactions, JMM defines eight operations to complete, each operation is atomic: Lock (acting on the main memory of the lock variable, which adds a variable is identified as an exclusive thread state), UNLOCK (acting on the unlocking main memory variable, which is a variable to the locked state is released , after the release of the variables can be locked by other threads), read (read), load (load), use (use), ASSIGN (assignment), store (storage), write (write). JMM Operator is required only to be executed sequentially, but not guaranteed to be performed continuously .
lock: (1) a variable at the same time allow only one thread operating its lock , but lock operation can be repeated multiple times with a thread, after repeatedly lock, unlock operation only perform the same number of variables will It is unlocked.
(2) If you do lock operation on a variable, it will clear the value of this variable working memory, prior to the execution engine to use this variable, we need to re-execute or assign value load operation initialized variables.
(3) before performing the unlock operation on a variable, this variable must be synchronized back to the first main memory (execution store, write operation)
Special rules volatile type variables
Volatile keyword can be said to be the most lightweight synchronization mechanism provided by the JVM .
A characteristic: to ensure the visibility of this variable for all threads, if one thread changes the value of this variable, the new value to other threads can be immediately learned . In each thread's working memory, volatile variables can also be present inconsistencies, but because they have to refresh before each use, the execution engine can not see the inconsistency, it is considered that there is no consistency problem. so that this action is to lock the CPU cache writes to main memory, the write operation will cause another CPU core or other disabling its cache, this operation corresponds to the cache variables described previously made a " store and write "operation , so by this operation, allowing front volatile variable changes immediately visible to other cpu
Two characteristics: prohibiting command reordering optimization, the following instructions can not be reordered to the position before the memory barrier means when reordering, the Lock instruction to modify the synchronization memory means before all of the operations have been completed execution , thus forming the "instruction reordering memory can not cross the barrier" effect
JMM atoms of how to handle concurrent process, visibility and orderliness
Atomicity: JMM since guaranteed operating variables include atomic read / load / assign / use / store / write, we can think of the basic data types have read and write access is atomic . If a scene requires a greater range of guaranteed atomicity, JMM also provided to lock and unlock operations to meet this demand, a higher level of monitorenter and monitorexit bytecode instructions implicitly using these two operations, the reflected java code is synchronized keyword sync blocks, and therefore in the operation block also includes a synchronized between atomicity .
Visibility: Visibility is when a thread changes the value of shared variables, other threads can be aware of this change immediately . JMM is synchronized back to main memory by changing after a new value in the variable before reading the value of this variable dependent on the main memory as a way to transfer media from the main memory to refresh the variable to achieve visibility, whether ordinary or volatile variables are variables is the case, the difference between ordinary variable and volatile variables that special rules volatile guarantee new value immediately synchronized to the main memory, and immediately refresh from main memory before each use . Because some, it can be said volatile guarantee visibility when multi-threaded operating variables, while the average variable can not guarantee this. synchronized and the final realization of visibility. Visibility is synchronized by the sync block "before performing the unlock operation on a variable, this variable must be synchronized back to the first main memory" rule obtained, and the visibility of the final keyword means: the final modified field Once initialization is complete builder, then you can see the final value of the field in the other thread .
Orderliness: the synchronized keyword is "in a variable at the same time allowing only one thread to its lock operation" obtained by the rule , this rule determines the two sync blocks hold the same lock can only be serial enter.