Why volatile Prevents Reordering: Inside Java’s Memory Model and CPU Architecture

volatile is a fundamental Java keyword often used in concurrent programming, but many developers are unclear about its low‑level mechanisms. This article explores the underlying principles of instruction reordering, memory visibility, and how the Java Memory Model (JMM) and the JVM guarantee correct behavior.

Instruction Reordering

Both the CPU (out‑of‑order execution) and the compiler may reorder instructions to improve performance. A classic example demonstrates how two threads can observe unexpected values (x = 0 && y = 0) due to such reordering.

static int x = 0, y = 0;
static volatile int a = 0, b = 0;
public static void main(String[] args) throws InterruptedException {
    for (int i = 0; true; i++) {
        x = 0; y = 0; a = 0; b = 0;
        Thread one = new Thread(() -> { a = 1; x = b; });
        Thread other = new Thread(() -> { b = 1; y = a; });
        one.start(); other.start();
        one.join(); other.join();
        if (x == 0 && y == 0) { System.err.println("bingo! i: " + i); break; }
    }
}

The happens‑before rules (program order, monitor lock, volatile variable, thread start, thread join, thread interrupt, object finalization, and transitivity) form the basis of the JMM. The JVM guarantees that these rules hold regardless of JIT optimizations.

CPU Cache and Memory Hierarchy

Modern CPUs are orders of magnitude faster than main memory, so they use a multi‑level cache (L1 > L2 > L3) based on temporal and spatial locality. Cache‑coherency protocols such as MESI ensure that multiple cores see a consistent view of memory.

Store Buffer and Memory Barriers

A store buffer allows a core to continue executing without waiting for cache‑coherency traffic. Memory barriers (inserted by volatile reads/writes) force the buffer to flush before subsequent memory operations, preventing reordering at the hardware level.

Compiler Reordering and Tiered Compilation

JIT compilers (C1, C2) may also reorder code. Tiered compilation in HotSpot progresses from interpreter to C1 profiling levels and finally to the aggressive C2 compiler. Disabling C2 (e.g., -XX:TieredStopAtLevel=3) eliminates the observed visibility bug, proving that C2 is responsible.

Practical Takeaways

Use volatile for shared mutable variables that need visibility guarantees.

Understand that adding volatile to the wrong variables (e.g., the data variables instead of the flags) does not solve the problem.

Be aware of the cost of memory barriers and cache‑coherency traffic.

In summary, volatile works by inserting a memory barrier that flushes the store buffer and leverages the cache‑coherency protocol, ensuring both ordering and visibility across threads.