What does 'happens-before' mean in the Java Memory Model, and why can code without synchronization see stale values across threads?

#Two Different Questions: Ordering and Visibility

Most developers think of concurrency bugs purely in terms of ordering — did thread A's write happen before thread B's read? The Java Memory Model (JMM) is actually answering a subtly different and stricter question: given two actions in different threads, is thread B guaranteed to observe the effect of thread A's action at all, and if so, is it guaranteed to see it in a particular order relative to other actions? Without an explicit guarantee, the JVM and the underlying hardware are both allowed to behave in ways that feel impossible if you're only thinking about program order.

#Why Reordering and Stale Reads Are Legal

Two independent mechanisms conspire to make unsynchronized code behave unpredictably across threads:

• Compiler and JIT reordering. As long as it doesn't change the observable behavior of a single thread, the compiler and the JIT are free to reorder, hoist, or even eliminate reads and writes. A loop that reads a field repeatedly with nothing in between that appears to modify it (from that thread's point of view) can have the read hoisted out of the loop entirely, turning while (flag) { ... } into an effectively infinite loop if flag is set by another thread.
• CPU caching and store buffers. Each core can keep a value in a private cache line or store buffer rather than writing straight through to main memory. A write from one core is not guaranteed to be visible to another core's cache until some memory-ordering instruction forces a flush — and a plain field write doesn't emit one.

Neither of these is a JVM bug. They exist because they make single-threaded code fast, and the JMM's whole design is to say precisely which cross-thread guarantees you get without giving those optimizations up — as long as you use the right synchronization primitives.

#The happens-before Relation

"Happens-before" is not about wall-clock time. A happens-before B means: the effects of A are guaranteed visible to, and ordered before, B, from B's point of view. If no happens-before edge connects two actions in different threads, the JMM allows B to observe any interleaving of A's effects — including none at all.

#A Real Visibility Bug

public class Worker implements Runnable {
    private boolean running = true; // BUG: not volatile

    @Override
    public void run() {
        int i = 0;
        while (running) {
            i++;
        }
        System.out.println("stopped after " + i + " iterations");
    }

    public void stop() {
        running = false;
    }
}

public class Main {
    public static void main(String[] args) throws InterruptedException {
        Worker worker = new Worker();
        Thread t = new Thread(worker);
        t.start();
        Thread.sleep(1000);
        worker.stop();
        t.join(); // can hang indefinitely — this is legal under the JMM
    }
}

There is no happens-before edge between worker.stop()'s write to running and the worker thread's read of running inside the loop. Depending on the JIT and the hardware, one of two things can go wrong: the JIT may hoist the read of running out of the loop entirely (nothing in the loop body appears, from the worker thread's perspective, to change it), turning the loop into while (true); or the write may simply sit in the main thread's store buffer / cache and never get flushed to where the worker's core can see it. Either way, t.join() can block forever, and this is not a rare hardware fluke — it is explicitly permitted by the specification whenever there is no synchronization.

#The Fix

public class Worker implements Runnable {
    private volatile boolean running = true; // FIX: volatile

    @Override
    public void run() {
        int i = 0;
        while (running) {
            i++;
        }
        System.out.println("stopped after " + i + " iterations");
    }

    public void stop() {
        running = false;
    }
}

Marking running volatile invokes the volatile variable rule: the write in stop() now happens-before every subsequent read of running, in every thread. That guarantees two things at once — visibility (the new value is guaranteed to be observed) and ordering (the compiler can no longer reorder other memory operations across that volatile access, which matters once more fields are involved). synchronized blocks around both the read and the write would fix the same bug through the monitor lock rule instead, and AtomicBoolean would fix it while also giving you atomic compound operations, which volatile alone does not.

#The Diagram

🧠 Check your understanding
0/3 · 0/3 answered
1. What does it mean for action A to 'happen-before' action B in the Java Memory Model?
A executes strictly earlier than B in wall-clock timeThe effects of A are guaranteed to be visible to, and ordered before, BA and B run on the same threadA completes before the JVM starts garbage collection
2. In the buggy Worker example, why can the while(running) loop run forever even though stop() sets running = false?
The JVM only allows one thread to run at a timeThread.sleep() prevents the write from ever executingBoolean fields cannot be shared between threads in JavaWith no synchronization or volatile, there is no happens-before edge guaranteeing the worker thread ever observes the new value, so the JIT/hardware may keep using a stale cached value
3. Why is marking a counter field volatile not enough to make counter++ thread-safe?
volatile fields are read-only after initializationvolatile only guarantees visibility and ordering for that field's individual reads/writes — it does not make the read-modify-write sequence of ++ a single atomic operationvolatile fields cannot be incrementedThe compiler ignores volatile on integer types