Since JDK5, the JMM has used the concept of happens-before to describe memory visibility between multiple threads. In the JMM, if the result of one operation needs to be visible to another, there must be a happens-before relationship between the two operations. The two operations mentioned here can be within the same thread or between different threads.

Happens-before principle

The happens-before principle is very important as it is the primary basis for determining whether data is competing and threads are safe, and it allows us to resolve all questions about whether there might be conflicts between two operations in a concurrent environment. For example, is

i=1; // thread A j= I; / / thread BCopy the code

Is j equal to 1? Assuming thread A’s happens-before thread B’s happens-before (j = I), then we can be sure that j = 1 is valid after thread B’s happens-before. If thread B does not have the happens-before principle, then j = 1 is not necessarily valid. The happens-before principle is defined as follows:

  1. If one action happens-before the other, the execution result of the first action will be visible to the second action, and the execution order of the first action precedes the second action.

  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. The reorder is not illegal if the result of the reorder is the same as the result of the happens-before relationship.

The first is for programmers, and for programmers’ convenience, by understanding the happens-before relationship: If A happens-before B, the Java memory model guarantees the programmer that the results of A’s operations will be visible to B, and that A takes precedence over B in execution order. Note that this is just a guarantee the Java memory model makes to the programmer! It’s not really unreorderable.

The second is the constraint principle for compiler and processor reordering. The compiler and processor can optimize as much as they like, as long as they don’t change the result of the program’s execution (i.e., single-threaded programs and properly synchronized multithreaded programs). So, the first one is just a convenience for the programmer, the programmer is only concerned with the result, as long as the result remains the same, it doesn’t really matter whether it’s reordered or not.

Happens-before rules

  1. Procedure order rule: For every action in a thread, happens-before any subsequent action in that thread. (I think we can summarize this informally by saying that the program is executed from the top down.)

  2. Monitor lock rule: a lock is unlocked, happens-before a lock is subsequently locked.

  3. Volatile variable rule: Writes to a volatile field, happens-before any subsequent reads to that volatile field. When a volatile variable is written, the JMM flusher the value of the shared variable from the thread’s local memory to main memory. When a volatile variable is read, the JMM invalidates the thread’s local cache and reads the variable from main memory.

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

  5. Start () rule: if thread A performs an operation threadb.start () (starts ThreadB), then thread A’s threadb.start () operation happens before any operation in ThreadB.

  6. Join () rule: if thread A performs the operation threadb.join () and returns successfully, any operation in ThreadB happens-before thread A returns successfully from threadb.join ().

  7. Program interrupt rule: A call to the thread interrupted() method detects the interruption before the code in the interrupted thread detects the interruption.

  8. Object Finalize rule: The finalization of an object (completion of constructor execution) precedes the start of the Finalize () method that generated it.

Happens-before relationship to JMM

The Art of Concurrent Programming in Java

My humble opinion, thank you for reading. Welcome to the discussion,Personal blog

JAVA concurrency (1) Concurrency programming challenges

JAVA concurrency (2) Underlying implementation principles of synchronized and volatile

JAVA concurrency (3) lock status

JAVA concurrency (4) atomic operation implementation principle

JAVA concurrency (5) happens-before

JAVA concurrency (6) reordering

JAVA concurrency (7) Analyze volatile against the JMM

JAVA concurrency (8) Final domain

JAVA concurrency (9) In-depth analysis of DCL

JAVA Concurrency (10) Concurrency programming basics