[Fighting Java Concurrency]-----Reordering of Java Memory Model

When executing a program, in order to provide performance, processors and compilers often reorder instructions, but they cannot be reordered at will. It is not how you want to sort it. It needs to meet the following two conditions:

1. The result of program running cannot be changed in a single-threaded environment;
2. Reordering is not allowed if there are data dependencies

If you have read LZ’s previous blog, You will know that in fact, these two points can be attributed to one thing: it cannot be deduced through the happens-before principle, and JMM allows arbitrary ordering.

as-if-serial semantics

as-if-serial semantics means that all operations can be reordered for optimization, but you must ensure that they are executed after reordering The result cannot be changed, and the compiler, runtime, and processor must adhere to as-if-serial semantics. Note that as-if-serial only guarantees a single-threaded environment and is invalid in a multi-threaded environment.

Let’s use a simple example to illustrate:

int a = 1 ;      //A
int b = 2 ;      //B
int c = a + b;   //C

The three operations of A, B, and C have the following relationship: A and B do not have data dependencies, and A and C, B and C has a data dependency relationship, so when reordering, A and B can be sorted arbitrarily, but they must be in front of C. The execution order can be A –> B –> C or B –> A –> C. But no matter what the execution order, the final result C is always equal to 3.

as-if-serail semantics protects single-threaded programs, which can ensure that the final result of the program is always consistent under the premise of reordering.

In fact, for the above code, they have such a happened-before relationship:

1. A happens-before B

2. B happens -before C

3. ##A happens-before C

1 and 2 are program sequence rules, and 3 is transitivity. However, doesn't it mean that through reordering, B may be executed before A? Why does A happen-before B? Here again, it is stated that A happens-before B is not that A will definitely be executed before B, but that A is visible to B, but relative to this program, the execution results of A do not need to be visible to B, and their reordering will not affect the results. So JMM will not consider this reordering illegal.

We need to understand this: improve the operating efficiency of the program as much as possible without changing the execution results of the program.

Below we are looking at an interesting piece of code:

public class RecordExample1 {
    public static void main(String[] args){        
    int a = 1;        
    int b = 2;        
    try {
            a = 3;           //A
            b = 1 / 0;       //B
        } catch (Exception e) {

        } finally {
            System.out.println("a = " + a);
        }
    }
}

According to the reordering rules, operation A and operation B may be reordered. If they are reordered, B will throw an exception. (/ by zero), statement A will definitely not be executed at this time, so will a still be equal to 3? If you follow the as-if-serial principle it changes the result of the program. In fact, the JVM does a special processing for exceptions. In order to ensure as-if-serial semantics, the Java exception handling mechanism does a special processing for reordering: JIT will insert error compensation in the catch statement during reordering. Code (a = 3), although doing so will cause the logic in cathc to become complicated, the JIT optimization principle is: optimize the logic under normal operation of the program as much as possible, even at the expense of the complexity of the catch block logic.

The impact of reordering on multi-threading

In a single-threaded environment due to as-if-serial semantics, reordering cannot affect the final result, but what about a multi-threaded environment?

The following code (classic usage of volatile):

public class RecordExample2 {
    int a = 0;    boolean flag = false;    
    /**
     * A线程执行
     */
    public void writer(){
        a = 1;                  
        // 1
        flag = true;            
        // 2
    }    /**
     * B线程执行
     */
    public void read(){        
    if(flag){                  
    // 3
           int i = a + a;          
           // 4
        }
    }

}

Thread A executes writer(), thread B executes read(), can thread B read a = 1 during execution? The answer is not necessarily (

Note: X86CPU does not support write-write reordering. If it is operated on x86, this will definitely be a=1. LZ did not test it for a long time, and finally found out after checking the information ).

Since there is no data dependency between operation 1 and operation 2, reordering can be performed. There is also no data dependency between operation 3 and operation 4. They can also be reordered, but operations 3 and 4 There is a control dependency between operations 4. If operation 1 and operation 2 are reordered:

According to this execution order, thread B will definitely not be able to read the a value set by thread A. The semantics of multi-threading here are It has been destroyed by reordering.

Operation 3 and operation 4 can also be reordered, which will not be explained here. But there is a control dependency relationship between them, because operation 4 will be executed only if operation 3 is established. When control dependencies exist in the code, it will affect the parallelism of the execution of the instruction sequence, so compilers and processors will use guessing execution to overcome the impact of control dependencies on parallelism. If operation 3 and operation 4 are reordered and operation 4 is executed first, the calculation result will be temporarily saved in the reordering buffer. When operation 3 is true, the calculation result will be written to variable i

Through the above analysis,

reordering will not affect the execution results of a single-threaded environment, but will destroy the execution semantics of multi-threads .

The above is the content of [Fighting Java Concurrency]-----Reordering of Java Memory Model. For more related content, please pay attention to the PHP Chinese website (www.php.cn)!