Concurrent programming practice 15-reordering, happens-before

• Instruction reordering
  In order to optimize the operating efficiency of the CPU, if conditions permit, the subsequent instructions that are currently capable of being executed immediately are directly executed, avoiding the waiting 3 when obtaining the data required by the next instruction. Through out-of-order execution technology, the processor can greatly improve the execution efficiency.
  For example: for the following code

int a = 10 // 1 
int b = 100 // 2
int c = a // 3

The actual execution process may be: 1-3-2, not: 1-2-3; because after the first step gets the value of a, the third part still needs to be used. At this time, because the second step does not Interfering with the logic of the program under a single thread will directly execute 3, and then execute 2. Avoid reading the value of a twice. (Just to illustrate the possible principle, the example is not necessarily correct)

• Data dependencies (as-if-serial)

  • As-if-serial semantics means that all actions (Action) 5 can be reordered for optimization, but it must be ensured that their reordered results are consistent with the expected results of the program code itself.
    which is
  • That is, if the subsequent logical calculation needs to depend on a previous value a, the calculation step of the value a cannot be skipped. The above code: In step 3, the value of c needs to use a, so you cannot skip 1 and directly execute 3

• happens-before rule
  Semantics : If A happens before B, then all changes made by A can be seen by B.
  Happens-before is used to specify the order of execution between two operations. Provides memory visibility across threads. In the Java memory model, if the result of one operation needs to be visible to another operation, there must be a happens-before relationship between these two operations.

Rules to follow:
* Program order rules: every operation in a thread, happens-before any subsequent operation in that thread.
* Monitor lock rules: unlocking a monitor lock happens-before then locking the monitor lock.
* volatile variable rules: a write to a volatile field happens-before any subsequent reads of this volatile field.
* Transitivity: If A happens- before B, and B happens- before C, then A happens- before C.

• Memory Semantics of Locks and Volatile: (JMM)

  • Lock acquisition: first clear the current thread value memory, and obtain the latest value from the main memory; lock release: refresh the current thread memory value to the main memory
  • The read and write of volatile corresponds to the acquisition and release of locks, the principle is similar

• 
  Reordering rules for final fields For final fields, the compiler and processor must obey two reordering rules

1> A write to a final field within a constructor, and subsequent assignment of a reference to this constructor to a reference variable, the two operations cannot be reordered
2> An initial read of a reference containing a final field object, and subsequent initial read This final field, the two operations cannot be reordered

Meituan Commentary Blog-Research on Java Memory
Access
Reordering