Talk about the happens-before principle of Java happens-before of the Java memory model

Regardless of the processor, the JVM, and the compiler, they will optimize the execution efficiency of instructions as much as possible under the premise that the program is correct, and perform operations such as instruction rearrangement. To ensure the correct execution result of the program, the happens-before principle specified in JMM must be followed.

In the Java Memory Model (JMM), if the execution result of one operation needs to be visible to another operation, the two operations must have a happens-before relationship. The happens-before principle is very important. It is the main basis for judging whether there is competition in data and whether threads are safe. It ensures visibility in a multi-threaded environment. According to this principle, all conflicts that may exist in concurrent operations can be resolved.

The happens-before principle mainly includes single-threaded program order rules, locking rules, volatile variable visibility rules, transitivity rules, thread start, interrupt, termination join rules, and object termination rules (initialization completion occurs first before its destruction operation)

The happens-before principle is defined as follows:

1. If an operation happens-before another operation, the result of the first operation will be visible to the second operation, and the first operation will be executed before the second operation.  
2. The existence of a happens-before relationship between two operations does not mean that they must be executed in the order specified by the happens-before principle. If the execution result after reordering is consistent with the execution result according to the happens-before relationship, then this kind of reordering is not illegal.

The following is the happens-before principle rule:

1. Program order rule: In a thread, according to the code order, the operation written in front occurs first before the operation written in the back;
2. Locking rules: an unLock operation occurs first and then faces the same lock operation;
3. volatile variable rule: a write operation to a variable occurs first before a subsequent read operation of the variable;
4. Delivery rule: If operation A occurs first in operation B, and operation B occurs in operation C first, it can be concluded that operation A occurs first in operation C;
5. Thread start rules: The start() method of the Thread object occurs first for each action of this thread;
6. Thread interrupt rules: The call to the thread interrupt() method occurs first when the code of the interrupted thread detects the occurrence of the interrupt event;
7. Thread termination rule: All operations in the thread occur first in the thread termination detection. We can detect that the thread has terminated execution through the end of the Thread.join() method and the return value of Thread.isAlive().
8. Object finalization rules: the initialization of an object occurs first at the beginning of its finalize() method;

Let's take a closer look at each of the above rules (from "In-depth Understanding of the Java Virtual Machine Chapter 12"):

Program order rule : The result of a piece of code executing in a single thread is ordered. Note that it is the execution result, because the virtual machine and the processor will reorder the instructions (reordering will be described in detail later). Although it is reordered, it does not affect the execution result of the program, so the final execution result of the program is consistent with the sequential execution result. Therefore, this rule is only valid for a single thread, and the correctness cannot be guaranteed in a multi-threaded environment.

Locking rule : This rule is easy to understand. Whether in a single-threaded environment or a multi-threaded environment, if a lock is locked, the unlock operation must be performed before the lock operation can be performed.

Volatile variable rule : This is a more important rule, which indicates that volatile guarantees thread visibility. In layman's terms, if a thread writes a volatile variable first, and then a thread reads the variable, the write operation must be a happens-before read operation.

Transit rule : The happens-before principle is transitive, that is, A happens-before B, B happens-before C, then A happens-before C

Thread start rule : Assuming that thread A starts thread B by executing ThreadB.start() during execution, then thread A's modification of shared variables is guaranteed to be visible to thread B after thread B starts executing.

Thread termination rule : Assuming that thread A waits for thread B to terminate by formulating ThreadB.join() during execution, then thread B's modification to shared variables before termination is visible after thread A waits to return.

The above eight are the rules that native Java satisfies the Happens-before relationship, but we can deduce other rules that satisfy the happens-before relationship from them:

1. The operation that puts an element into a thread-safe queue Happens-Before the operation that removes the element from the queue
2. The operation that puts an element into a thread-safe container Happens-Before the operation that removes the element from the container
3. Countdown operation Happens-Before CountDownLatch#await() operation on CountDownLatch
4. Release Semaphore License ActionHappens-Before Acquire License Action
5. All operations of tasks represented by Future Happens-Before Future#get() operations
6. Submit a Runnable or Callable operation to the Executor Happens-Before task starts the operation

Let’s repeat the concept of happens-before here: if there is no happens-before rule for the two operations (the first 8 + the last 6), then there is no order guarantee for these two operations, and the JVM can operations to reorder. If operation A happens-before operation B, then what operation A does in memory is visible to operation B.

The happens-before of the Java memory model