The Java Memory Model & Performance — Visibility and Speed

Two advanced realities shape correct, fast Java. First, the Java Memory Model (JMM): because compilers and CPUs reorder and cache memory for speed, a write by one thread is not automatically visible to another. volatile guarantees visibility (but, crucially, not atomicity), and happens-before is the precise set of rules that decide when writes are seen — the foundation under synchronized and atomics. Second, performance: the JVM doesn't run your bytecode the same way forever — it interprets it at first, then JIT-compiles hot methods to optimized native code, and a garbage collector reclaims unused objects in short pauses. You can watch both happen with diagnostic flags. Understanding visibility keeps concurrent code correct; understanding the JIT and GC keeps it fast.

This is the deep pass of happens-before. Every output below was produced by running the code; JIT and GC logs are real captured excerpts, labeled illustrative because their exact lines and timings vary per run and machine.

Table of contents

1. volatile: visibility, not atomicity
2. happens-before, in depth
3. Safe publication: reordering, final, and double-checked locking
4. JIT compilation
5. Garbage collection and tuning
6. Mental-model summary
7. Gotcha checklist

1. volatile: visibility, not atomicity

A volatile field is always read from and written to main memory, never a stale CPU cache — so one thread's write is visible to others. This fixes the "a thread never sees the flag change" bug: here a worker spins until main flips a volatile flag, and it stops.

Output:

worker saw running=false and stopped
done

Analysis. The worker loops on running; after 100 ms main sets running = false, the worker sees it (because volatile forces a fresh read), exits its loop, and the program ends. Without volatile, the worker could keep reading a cached true forever — the program would hang. volatile established the happens-before edge that made the write visible.

That "would hang" is not hypothetical — delete the one keyword and it does. Shown statically, because a hung program never finishes (the sandbox would only time out):

public class Main {
    static boolean running = true;   // volatile removed — nothing else changed
    public static void main(String[] args) throws InterruptedException {
        Thread worker = new Thread(() -> {
            long count = 0;
            while (running) count++;
            System.out.println("worker saw running=false and stopped");
        });
        worker.start();
        Thread.sleep(100);
        running = false;
        worker.join();
        System.out.println("done");
    }
}

Output (real captured run on Java 21):

(no output at all — the worker was still spinning 5 seconds after main set
 running = false; we killed the process. Neither println was ever reached.)

The mechanism is the JIT from §4: with no happens-before edge on running, the compiler may hoist the read out of the loop — the worker's loop becomes if (running) while (true) count++;, a perfectly legal transformation of code that promised no other thread would touch the field. The write from main arrives in memory; the worker just never looks again.

Intuition. Mechanism. A volatile write flushes to main memory and a volatile read fetches from it, with a happens-before edge between them — so a reader after the write is guaranteed to see it (and everything written before it). It prevents the JVM/CPU from caching the field in a register or reordering around it.

Concrete bite. volatile gives visibility but not atomicity — a volatile counter's ++ still races:

Output (illustrative — wrong and varying; three real runs printed 154723, 166782, 153592):

154723

Even though counter is volatile, counter++ is still read-modify-write — and volatile makes each access visible, not the trio atomic. So updates are still lost, just as without volatile. Visibility ≠ atomicity: for an atomic counter you need AtomicInteger or a lock.

2. happens-before, in depth

Happens-before is the JMM's guarantee: if action A happens-before action B, then A's effects (all its writes) are visible to B. Without such an edge, there's no guarantee — B may see stale data. A few rules establish these edges:

Analysis. The four common sources of happens-before edges: program order (statements in one thread happen-before later ones in that thread); a monitor unlock happens-before a later lock of the same monitor (why synchronized publishes writes); a volatile write happens-before a later read of it (§1); and Thread.start() happens-before the thread's run, while a thread's actions happen-before another's return from join(). Each is a bridge across which writes are guaranteed visible.

Intuition. Mechanism. Happens-before is transitive: if A → B and B → C then A → C. So publishing one volatile flag after writing several plain fields makes all those fields visible to a reader that reads the flag — the flag's happens-before edge carries the earlier writes with it — the "safe publication" idiom that §3 develops in full.

Concrete bite. The relation is the only guarantee — two unrelated threads with no edge between them can see each other's writes in any order, or not at all. "It seemed to work" is meaningless; correctness requires an actual happens-before edge, which is why every shared-state access needs synchronized, volatile, or a java.util.concurrent tool.

3. Safe publication: reordering, final, and double-checked locking

§2's rules have a consequence that surprises even experienced developers: a constructor is not a fence. Consider one thread building an object and handing it to another through a plain field:

// Thread A                          // Thread B
config = new Config("prod", 42);     if (config != null) {
                                         use(config.name);   // can see null!
                                     }

Inside new Config(...) there are several writes: the fields, then the reference config itself. Within Thread A, program order makes that look sequential — but program order is an edge inside one thread only. For Thread B, reading config through a plain field, there is no happens-before edge at all — so the JMM permits B to see the reference before the field writes it "should" carry. B observes a non-null config whose name is still null: a half-built object. (This one is told, not shown: the reorder is real but depends on the JIT and CPU catching the window, so it isn't reliably capturable in a demo — which is precisely what makes it dangerous. The fix below runs.) Publishing an object so that its fields travel with the reference is called safe publication, and there are exactly three tools:

1. final fields. The JMM gives constructors one free guarantee: if a field is final, its value (as of the end of the constructor) is visible to every thread that sees the object reference — no volatile, no lock. This is the deepest reason this book's records and immutable classes are concurrency gold: an object whose fields are all final cannot be seen half-built.
2. A volatile reference. The volatile write of the reference happens-before the volatile read, and (by §2's transitivity) carries every earlier write — the fields — with it.
3. A lock. Publish and consume under the same monitor; the unlock→lock edge carries the writes.

The classic place all three collide is the lazily initialized singleton. The infamous double-checked locking pattern — check, lock, check again, construct — was broken for years when written with a plain field: the unlocked first check could observe the half-built object. With volatile, the pattern is correct, and here it is running:

Output (illustrative — thread order varies; the "constructed once" line appears exactly once, every run):

Config constructed once, by Thread-0
Thread-0 got loaded
Thread-1 got loaded
Thread-2 got loaded
Thread-3 got loaded

Analysis. Four threads raced into getInstance(); exactly one constructed the Config (the lock plus the second check guarantee it), and the volatile write published it so the other threads' unlocked fast-path reads still saw a fully built object. Remove volatile and the fast path becomes the unsafe publication above — rare, timing-dependent, catastrophic. Worth knowing: the initialization-on-demand holder idiom (a private static nested class whose static final field holds the instance) gets the same laziness and safety from the class loader with no volatile and no lock — simpler, and what you should usually write.

Intuition. Mechanism. The JIT and CPU may commit the reference-write before the field-writes unless something forbids it; final fields add a freeze at constructor exit, volatile adds a write→read edge, and a monitor adds unlock→lock. All three are §2's rules aimed at one moment: the instant an object becomes reachable by another thread.

Concrete bite. The bug's signature is its rarity: unsafe publication can run clean for months on one JVM/hardware combination and then produce impossible-looking NullPointerExceptions on another (different CPU memory model, different JIT decisions). It cannot be caught by testing on your machine — only by reasoning about edges.

4. JIT compilation

The JVM runs bytecode by interpreting it at first, then Just-In-Time compiling methods that run often ("hot") into optimized native code. You can watch it with -XX:+PrintCompilation. Here a hot fib method gets compiled, then recompiled at a higher optimization tier:

$ java -XX:+PrintCompilation Main
...
20    6       3       Main::fib (24 bytes)
20    7       4       Main::fib (24 bytes)
21    6       3       Main::fib (24 bytes)   made not entrant
...

Output (illustrative excerpt — exact lines and timings vary every run):

20    6       3       Main::fib (24 bytes)
20    7       4       Main::fib (24 bytes)
21    6       3       Main::fib (24 bytes)   made not entrant

Analysis. Each line is a compilation event: a timestamp (ms), a compile id, a tier (3 = the C1 compiler, quick; 4 = C2, fully optimized), and the method. fib was first compiled at tier 3, then — once it proved very hot — recompiled at tier 4, and the tier-3 version was "made not entrant" (retired in favor of the faster one). This is why Java warms up: the same code runs faster after the JIT has compiled and optimized its hot paths, which is why micro-benchmarks must warm up before measuring.

Intuition. Mechanism. The JVM profiles execution counts and branch behavior while interpreting, then compiles hot methods — applying inlining, loop optimizations, and speculative optimizations based on the observed profile. If an assumption is later violated, it deoptimizes back to the interpreter and recompiles ("made not entrant").

Concrete bite. This makes naive timing lie: the first thousand calls to a method run interpreted and slow; later calls run optimized and fast. Timing a method "once" measures interpretation, not steady-state performance — which is why you warm up (run it many times) before measuring, and why a real benchmark uses a harness like JMH.

5. Garbage collection and tuning

Java manages memory automatically: a garbage collector reclaims objects no longer reachable, so you never free. Modern collectors are generational — most objects die young, so the GC scans a small "young" region frequently and cheaply. Watch it with -Xlog:gc on a program that allocates a lot of short-lived arrays:

$ java -Xlog:gc Main
[0.022s][info][gc] GC(0) Pause Young (Normal) (G1 Evacuation Pause) 24M->1M(516M) 0.725ms
[0.056s][info][gc] GC(1) Pause Young (Normal) (G1 Evacuation Pause) 300M->1M(516M) 0.536ms
[0.068s][info][gc] GC(2) Pause Young (Normal) (G1 Evacuation Pause) 300M->1M(516M) 0.506ms
...
allocated 2000 MB of garbage

Output (illustrative excerpt — counts, sizes, and pause times vary per run):

[0.056s][info][gc] GC(1) Pause Young (Normal) (G1 Evacuation Pause) 300M->1M(516M) 0.536ms

Analysis. The program allocated ~2 GB of 1 MB arrays, but they're immediately garbage, so the GC reclaimed them in many tiny pauses. Read one line: G1 (the default collector since JDK 9) ran a Young collection, reclaiming the young generation from 300M down to 1M (almost all of it was garbage), out of a 516M heap, in 0.536 ms. The heap never grew toward 2 GB because the collector kept recycling the same space. Sub-millisecond pauses for hundreds of MB is why automatic memory management is practical.

Intuition. Mechanism. The heap is split into generations; new objects go in the young gen, which fills and is collected quickly (survivors are promoted). Because the object lifetime hypothesis holds — most objects die young — young collections touch little live data and are fast. -Xmx/-Xms size the heap; -XX:+UseZGC (or others) selects a collector tuned for low pause times.

Concrete bite. Automatic GC doesn't mean "no memory bugs": a memory leak in Java is unintended reachability — objects you forgot to remove from a static collection or cache stay reachable, so the GC can't reclaim them, and the heap grows until OutOfMemoryError. The GC frees the unreachable; keeping a reference alive defeats it.

6. Mental-model summary

7. Gotcha checklist

Your Turn

Before you move on, check your understanding with the coach — explain the idea, apply it, weigh the trade-offs, then defend your reasoning.