Principles of Java Visibility Mechanism

Basic concepts

1. Visibility

When one thread modifies a shared variable, another thread can read the modified value.

2. Memory Barriers

A set of instructions for the processor to implement sequential restrictions on memory operations.

3. Buffer Line

The CPU tells the smallest unit of storage that can be allocated in the cache, and when the processor fills in the cache line, the entire cache line is loaded.

4.Lock prefixed instructions

Lock prefixed instructions will do two things on a multi-core processor:

1) Associate the data of the current processor’s cache line into the system memory.

2) This operation of writing back to the memory will invalidate the data cached by other CPUs at the memory address.

5. Cache coherence protocol

Under multi-processor, zero guarantees that the cache of each processor is consistent. Each processor will check whether the value of its cache is consistent by sniffing the data spread on the bus. expired. When the processor finds that the address corresponding to its cache line has been modified, it will set the current processor's cache line to an invalid state. When the processor reads or writes this data, it will re-read the data from the memory into the processor cache.

6.CAS

CompareAndSwap Compare and swap

CAS operation requires inputting two values, an old value (the value before performing the CAS operation, the expected value) and a new value. This is only possible when the current value is equal to the old value. Sets the current value to the new value, otherwise does not set it. This is an atomic operation, guaranteed by hardware.

7. Reordering rules

Fundamentally, JMM has only one reordering restriction for compilers and processors, as long as the results of program execution are not changed (referring to single-threaded or correctly synchronized multi-threaded environments) , then the compiler and processor can optimize it.

Volatile

As can be seen from the above Lock prefix instructions and cache consistency protocol, this is the implementation principle of volatile.

In fact, when the valatile variable is written, a Lock prefix is ​​indeed added to achieve the purpose of visibility.

final

The Final field can only be explicitly assigned once, but this does not mean that the final field cannot be initialized multiple times.

For example: final int i; i will be initialized to the default value: 0 before it is assigned in the constructor. This can be proven by debugging the code.

In order to ensure that the value of the final field will not be accessed before initialization, the programmer only needs to ensure one thing: that is, in the constructor, the object being constructed (this) does not "escape". Then without any synchronization means, it can be guaranteed that the final fields seen by any thread, including basic types and reference types, have been correctly initialized through the constructor.

An example of an object being constructed escapes:

public class FinalTest{ 
   final int i; 
   static FinalTest obj; 
 
   public FinalTest(){ 
   i  =1; 
   /** 
   *这里会使正在被构造的对象逸出，如果和上一句做了重排序，那么其他线程就可以通过obj访问到还为被初始化的final域。 
   **/ 
   obj = this;  
  } 
}

Happens-Before rule

The meaning of happens-before

Happen-Before rule is used to describe the sequential relationship between two operations. These two The operation can be in one thread or not. This order does not strictly mean execution time order, but rather that the results of the previous operation are visible to the subsequent operation.

Happens-Before relationship is defined as follows:

If one happens-before another operation, then the execution result of the first operation is visible to the second operation, and the execution order of the first operation is ranked after the second operation The existence of a happens-before relationship between two operations does not mean that the specific implementation of the Java platform must be executed in the order specified by the happens-before relationship. If the execution result after reordering is consistent with the execution result according to the happens-before relationship, then this reordering is not illegal.

For example, if A precedes B in the order of program execution, and A modifies a shared variable, and B happens to use the shared variable, then A needs to happen-before B. To put it more bluntly, A has to share The modification of variables needs to be visible to B when B is executed.

happens-before rule

Program sequence rule: Every operation in a thread happens-before any subsequent operation in that thread.

Monitor lock rules: Unlocking a lock happens-before the subsequent locking of the lock.

volatile rule: A write to a volatile field happens-before any subsequent read of this volatile field.

Transitivity: If Ahappens-before B, and B happens-before C, then A happens-before C.

start() rule: If thread A performs the operation ThreadB.start(), then the ThreadB.start() operation of thread A happens-before any operation in thread B.

join() rule: If thread A performs the ThreadB.join() operation and returns successfully, then any operation of thread B happens-before thread A returns successfully from the ThreadB.join() operation.

Explanation of all these rules: Ahappens-before B does not mean that A must happen before B, but it means that if A has happened before B, then the operation result of A must be visible to B