The two-tier semantics of the volatile keyword once a shared variable (a member variable of a class, a static member variable of a class) is modified by volatile, then there is a two-layer semantics: 1) The visibility of a variable is guaranteed by a thread that modifies the value of a variable. This new value is immediately visible to other threads. 2) command reordering is prohibited. According to the semantics of volatile, we can see that volatile is mainly aimed at the concurrency of three elements (atomicity, visibility and order) in the latter two have a practical optimization effect. Visibility: The thread itself does not interact directly with the main memory, but rather through the working memory of the thread to perform the corresponding operation. This is also an essential reason for the non-visibility of data between threads. Therefore, to achieve the visibility of volatile variables, directly from this point. The main difference between a write operation on a volatile variable and a normal variable is two: (1) Modifying a volatile variable forces the modified value to be refreshed in main memory. (2) Modifying a volatile variable causes the value of the corresponding variable in the working memory of other threads to be invalidated. Therefore, reading the value of the variable again requires a re-reading of the value from the main memory. With these two operations, you can solve the problem of visibility of volatile variables. Order: Volatile triggers the JVM's memory barrier policy memory barrier Policy: (1) loadload barrier execution order: load1->loadload->load2 Ensure that Load2 and subsequent load instructions can access the data that Load1 loads before loading the data. (2) Storestore barrier execution order: Store1->storestore->store2 ensure that the data Store1 operation is visible to other processors before Store2 and subsequent store instructions are executed. (3) Loadstore barrier execution order: Load1->loadstore->store2 ensures that Store2 and subsequent store instructions can access the data that is loaded into the Load1 before execution. (4) Storeload barrier execution sequence: store1-> storeload->load2 reads and writes to volatile each time, according to the table above, will trigger the corresponding CPU instruction, from the thread memory buffer to the previous changed variable brush to the main deposit. In simple terms, volatile affects the optimization strategy of the JVM instruction set to some extent, and the instruction set before and after the volatile does not go out of order to execute the volatile variable. The set of instructions before and after the temporary volatile is not correlated, jVMS can be executed in a random order. The JVM's volatile strategy, to some extent, implements the JVM's Happens-before principle (the first occurrence principle) in a discounted manner, as described below.
- Program Order rules: Within a thread, in code order, the preceding operation precedes the operation that is written in the back
- Locking rule: A unlock operation occurs after the face of the same lock amount lock operation
- Volatile variable rule: The write operation of a variable precedes the read operation that faces the variable.
- Delivery rule: If operation a precedes operation B, and Operation B precedes Operation C, it can be concluded that operation a precedes operation C
- Thread Start rule: the Start () method of the thread object takes precedence over each action of this thread
- Thread Break rule: The call to the thread interrupt () method occurs when the code of the interrupted thread detects that the interrupt event occurred
- Thread termination rule: All operations in a thread occur first in thread termination detection, and we can detect that the thread has terminated execution by means of the Thread.Join () method end, Thread.isalive () return value
- Object Finalization rule: Initialization of an object occurs at the beginning of his finalize () method
Volatile common usage scenarios:
(1) Status Mark Amount
(2) Single-case mode security release
(3) Low overhead read/write lock
Reference Document: Java concurrency programming: volatile keyword resolution http://www.cnblogs.com/dolphin0520/p/3920373.html java Multithreading: volatile variables, Happens-before relationship and memory consistency http://www.importnew.com/17149.html java concurrency Programming: the use and principles of volatile http://www.cnblogs.com/ Paddix/p/5428507.html "Java Theory and Practice: Using volatile variables correctly" https://www.ibm.com/developerworks/cn/java/j-jtp06197.html
Java Concurrency programming volatile keyword parsing
