Understanding Java Memory Model, Reordering, Memory Barriers, and volatile/final Semantics

1. Java Memory Model

Hardware Processing

Computer hardware consists of CPU, memory, disk, and data bus. The CPU uses caches for faster computation and synchronizes with main memory, as illustrated in the diagram.

To fully utilize execution units, processors may reorder instructions internally, then reassemble results to ensure single‑thread consistency.

Java Memory Model

The JMM defines language‑level rules for variable access, specifying how variables are stored in main memory and accessed via each thread's working memory.

All variables reside in main memory; each thread has its own working memory, and operations on variables must occur in the working memory. The diagram shows the logical interaction among threads, main memory, and working memory.

Memory Interaction Operations

The JMM defines eight operation instructions for memory interaction.

read – read a value from main memory; load – place the read value into working memory.

read is like a delivery truck bringing a package to a station; load unloads it at the station.

use – transfer a variable from working memory to the execution engine; assign – assign a value in the execution engine.

use distributes the package to a courier; assign starts delivery.

store – transfer a variable from working memory to main memory; write – store the variable in main memory.

store and write are like a courier delivering a package to your door and you signing for it.

lock – mark a main‑memory variable as exclusively owned by a thread; unlock – release the lock.

The diagram below shows the instruction interaction between working memory and main memory.

Instruction Rules

read and load, store and write must appear as pairs.

After an assign operation, the variable must be flushed back to main memory.

Only one thread can lock a variable at a time; locks are re‑entrant, and unlock must be called the same number of times.

Locking clears the thread's working‑memory copy, requiring a subsequent load or assign.

Before unlock, the variable must be synchronized to main memory (store/write).

2. Reordering

During compilation and execution, three kinds of reordering can occur: compiler‑level, instruction‑level parallelism, and memory‑system reordering. The diagram illustrates these possibilities.

Examples of reordering: a=1; b=a cannot be reordered because b depends on a, whereas a=1; b=2 may be reordered to b=2; a=1 .

Compiler optimization reorders statements without changing single‑thread semantics.

Instruction‑level parallelism allows independent instructions to execute out of order.

Memory‑system reordering occurs due to caches making loads and stores appear out of order.

Code examples are referenced in the original article.

3. Memory Barriers

The JMM inserts memory barriers to prevent certain compiler and processor reorderings, providing visibility guarantees for volatile and final variables.

Conceptually, a memory barrier is a fence that prevents later instructions from moving before it.

Four types of JMM memory‑barrier instructions

LoadLoad – ensures a preceding load completes before a subsequent load.

LoadStore – ensures a preceding load completes before a subsequent store.

StoreStore – ensures a preceding store completes before a subsequent store.

StoreLoad – ensures a preceding store completes before a subsequent load.

Different processor architectures support different reorderings; for example, x86 does not reorder LoadLoad, so a LoadLoad barrier may be omitted.

4. volatile Memory Semantics

volatile guarantees visibility and prevents certain reorderings. When a volatile variable is written, the thread’s local copy is flushed to main memory; when read, the local copy is invalidated and the value is reloaded from main memory.

These rules ensure that writes to volatile variables become visible to other threads.

volatile memory‑barrier insertion rules

Example code (kept unchanged):

class X {
    int a, b;
    volatile int v, u;
    void f() {
        int i, j;
        i = a; // load a
        j = b; // load b
        i = v; // volatile load
        // LoadLoad
        j = u; // volatile load
        // LoadStore
        a = i; // store a
        b = j; // store b
        // StoreStore
        v = i; // volatile store
        // StoreStore
        u = j; // volatile store
        // StoreLoad
        i = u; // volatile load
        // two barriers LoadLoad and LoadStore
        j = b; // load b
        a = i; // store a
    }
}

The code follows the volatile barrier rules.

5. final Memory Semantics

final fields cannot be modified after initialization. The JMM enforces two reordering rules for final fields:

Write rule: a write to a final field inside a constructor and the subsequent publication of the object reference cannot be reordered; the compiler inserts a StoreStore barrier after the final field write.

Read rule: the first read of an object reference and the first read of its final field cannot be reordered; the compiler inserts a LoadLoad barrier before reading the final field.

These rules guarantee that a final field is correctly initialized before any thread can see the object reference.

References

《Java并发编程的艺术》

《深入理解Java虚拟机》

http://ifeve.com/jmm-cookbook-mb/

http://www.cnblogs.com/chenyangyao/p/5269622.html

http://www.importnew.com/7553.html