The Java Memory Model & Performance — Visibility and Speed

Two advanced realities shape Java code that is both correct and fast.

• The Java Memory Model (JMM). For speed, compilers and processors reorder and cache memory operations, so a write by one thread is not automatically visible to another. volatile guarantees visibility, but not atomicity. Happens-before is the precise set of rules that decides when writes are seen. It's the foundation underneath both synchronized and atomics.
• Performance. The JVM doesn't run your bytecode the same way forever. At first it interprets it, and then it JIT-compiles hot methods into optimized native code. Meanwhile, a garbage collector reclaims unused objects in short pauses. You can watch both happen with diagnostic flags.

Understanding visibility keeps your concurrent code correct; understanding the JIT and the GC keeps it fast.

This lesson takes a deeper pass at happens-before. Every output below was produced by running the code. The JIT and GC logs are real captured runs that use JVM flags the sandbox can't pass. They're labeled illustrative, because their exact lines and timings vary from run to run and machine to machine.

You'll be able to: predict whether a thread sees a flag change with and without volatile, and explain why a volatile counter still loses updates; trace the happens-before edge that makes a plain write visible through a volatile flag; choose a safe way to publish an object (final fields, volatile, a lock, the holder idiom), and explain why double-checked locking needs volatile; read a -XX:+PrintCompilation line, and explain why a benchmark must warm up; read a -Xlog:gc line, and explain why a reachable object leaks.

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
8. Check yourself
9. Sources

1. volatile: visibility, not atomicity

A field may be declared volatile, "in which case the Java Memory Model ensures that all threads see a consistent value for the variable" [1]. A write to it is visible to every later read by other threads, which fixes the "a thread never sees the flag change" bug. Here, a worker spins until main flips a volatile flag — and then 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 the change, exits its loop, and the program ends. The volatile write happens-before every later read of the field, so the worker's next read returns false.

Without volatile, the worker may read true forever, and the program hangs. That's not hypothetical: delete that one keyword, and it does hang. If you press Run, it prints nothing and never finishes, so the sandbox stops it at its time limit.

// expects-hang: without volatile, the worker may never see running = false
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 JDK 25):

(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 JLS describes this exact bug, for a loop on a non-volatile field. The compiler "is free to read the field this.done" just once, "and reuse the cached value in each execution of the loop" [2].

In effect, the worker's loop becomes if (running) while (true) count++;. That's a perfectly legal transformation of code that never said another thread would touch the field. The write from main does happen — the worker just never looks again.

Intuition. Mechanism. A volatile write happens-before every later read of that field [3]. So a reader that comes after the write is guaranteed to see it, along with everything written before it. The JIT may not keep the field in a register, or reorder other memory operations across it, in any way that would break that guarantee.

Concrete bite. volatile gives you visibility, but not atomicity. A volatile counter's ++ still races:

Output (illustrative — wrong and varying; three runs on JDK 25 printed 135052, 145718, 139859):

135052

Even though counter is volatile, counter++ is still a read-modify-write. volatile makes each access visible, but it doesn't make the three steps atomic. So updates still get lost, just as they did without volatile. Visibility isn't 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 writes are visible to B. Without such an edge, there's no guarantee at all, and B may see an older value. A handful of rules establish these edges [3]:

Analysis. The four common sources of happens-before edges:

• Program order: "If x and y are actions of the same thread and x comes before y in program order, then hb(x, y)."
• Monitor lock: an unlock happens-before every later lock of the same monitor. That's why synchronized publishes writes.
• volatile: a write happens-before every later read of that field (§1).
• Start and join: Thread.start() happens-before the started thread's actions, and a thread's actions happen-before another thread returns from join() on it.

Think of each one as a bridge, across which writes are guaranteed to be visible.

Intuition. Mechanism. Happens-before is transitive: "If hb(x, y) and hb(y, z), then hb(x, z)" [3]. So a writer can set several plain fields and then write a single volatile flag — and a reader that sees the flag also sees those fields:

1. Program order: data = 42 happens-before ready = true in the writer.
2. volatile: the write ready = true happens-before the reader's read that sees true.
3. Program order: that read happens-before the reader's read of data.

Chain those three together, and data = 42 happens-before the reader's read of data:

Output:

reader sees data=42 label=answer

This output is guaranteed, not lucky: the flag's edge carries the earlier writes along with it. That's the "safe publication" idiom that §3 develops.

Concrete bite. This relation is the only guarantee you get. Two threads with no edge between them can see each other's writes in any order, or not at all. "It seemed to work" means nothing; correctness needs an actual happens-before edge. That's why every access to shared state needs synchronized, volatile, or a java.util.concurrent tool.

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

§2's rules have a surprising consequence: a constructor is not a fence. Picture one thread building an object and handing it to another thread 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: first the fields, then the reference config itself.

• Within Thread A, program order makes that sequence look fixed. But program order is an edge inside a single thread only.
• Thread B reads config through a plain field, so there's no happens-before edge at all between A's writes and B's reads.
• So the JMM permits B to see the reference before the field writes. B can observe a non-null config whose name is still null: a half-built object.

This one is described rather than demonstrated. The reordering is allowed, but it depends on the JIT and the processor hitting the window, so no demo captures it reliably — and that's precisely what makes it dangerous. The fixes below, however, do run.

Publishing an object so that its fields travel along with the reference is called safe publication. There are three tools for it, plus a fourth that the class loader gives you:

1. final fields. The JLS guarantees them. A thread that sees the reference only after the object "has been completely initialized is guaranteed to see the correctly initialized values for that object's final fields" [4]. The object counts as initialized "when its constructor finishes", so the constructor must not let this escape to another thread before it ends.
2. A volatile reference. The volatile write of the reference happens-before the volatile read. By §2's transitivity, it carries every earlier write along with it, the fields included.
3. A lock. Publish and consume under the same monitor, and the unlock→lock edge carries the writes.

This is the deepest reason records are safe to hand between threads. A record's component fields are "private, final, and non-static" [5]. The guarantee also covers objects reached through those final fields, as they were when the constructor finished [4]. It doesn't cover changes made after construction, though: a record holding a mutable ArrayList is only shallowly immutable.

The classic place where these tools collide is the lazily initialized singleton. The infamous double-checked locking pattern (check, lock, check again, construct) is broken when written with a plain field, because the unlocked first check can 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-2 got loaded
Thread-0 got loaded
Thread-3 got loaded
Thread-1 got loaded

Analysis. Four threads raced into getInstance(), and exactly one of them constructed the Config — the lock plus the second check guarantee that. 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 described above: rare, timing-dependent, and catastrophic.

The holder idiom gets the same laziness and safety from the class loader, with no volatile and no lock. A class is initialized "immediately before" its first use, such as the first read of one of its static fields [6]. The JVM synchronizes that initialization, so exactly one thread runs it [7]:

Output:

main started; nothing constructed yet
Config constructed
all four got loaded

Holder wasn't initialized when Main started, so nothing was constructed yet. The first getInstance() triggered the initialization — exactly once, no matter how many threads raced there.

Intuition. Mechanism. Unless something forbids it, the JIT and the processor may make the reference write visible before the field writes. final fields add a guarantee at constructor exit; volatile adds a write→read edge; a monitor adds unlock→lock; and class initialization adds its own lock. All of them are §2's rules, aimed at one moment: the instant an object becomes reachable by another thread.

Concrete bite. The signature of this bug is its rarity. Unsafe publication can run clean for months on one JVM and processor, then produce impossible-looking NullPointerExceptions on another, with a different memory model or different JIT decisions. Testing on your machine can't catch it; only reasoning about edges can.

4. JIT compilation

At first, the JVM runs bytecode by interpreting it. Methods that run often ("hot" methods) then get JIT-compiled: compiled into optimized native code while the program is running. By default, the JVM uses a "Tiered compiler, using both C1 and C2" [8]: C1 compiles quickly, and C2 optimizes fully. This program makes fib hot:

Output:

fib(30) = 832040

The flag -XX:+PrintCompilation prints "a message to the console every time a method is compiled" [9]. The sandbox can't pass JVM flags, so this is a terminal run, filtered down to the lines about Main:

$ java -XX:+PrintCompilation Main | grep -E "Main::|fib\(30\)"
16    9       3       Main::fib (23 bytes)
17   10       4       Main::fib (23 bytes)
17    9       3       Main::fib (23 bytes)   made not entrant: not used
fib(30) = 832040

Output (illustrative — real captured run on JDK 25; the timestamps and ids vary every run):

16    9       3       Main::fib (23 bytes)
17   10       4       Main::fib (23 bytes)
17    9       3       Main::fib (23 bytes)   made not entrant: not used

Analysis. Each line is a compilation event: a timestamp in milliseconds, a compile id, a tier, and the method with its bytecode size.

• In HotSpot's source, tier 3 is "C1, invocation & backedge counters + mdo" (C1 with full profiling), and tier 4 is C2 [10].
• fib was compiled at tier 3 first. Once it proved very hot, it was recompiled at tier 4.
• The tier-3 version was then "made not entrant" — retired in favour of the faster one, because it was no longer used.

This is why Java warms up: the same code runs faster once the JIT has compiled and optimized its hot paths.

Intuition. Mechanism. While interpreting, the JVM counts calls and records how branches behave. It then compiles hot methods, applying inlining, loop optimizations and speculative optimizations based on that profile. If one of its assumptions later turns out to be wrong, it deoptimizes: it falls back to the interpreter, and later recompiles.

Concrete bite. This makes naive timing lie. The first calls to a method run interpreted and slow; later calls run optimized and fast. So timing a method once measures interpretation, not steady-state performance. That's why you warm up (run the code many times) before measuring, and why a real benchmark uses a harness such as JMH [11].

5. Garbage collection and tuning

Java manages memory automatically. A garbage collector reclaims objects that are no longer reachable, so you never free memory yourself. "A reachable object is any object that can be accessed in any potential continuing computation from any live thread" [13]. The object-model lesson shows when an object becomes unreachable.

Modern collectors are generational. They rely on "the weak generational hypothesis, which states that most objects survive for only a short period of time" [12]. So the GC scans a small "young" region often, and cheaply. This program allocates 2000 MB worth of short-lived 1 MB arrays:

Output:

allocated 2000 MB of garbage

You can watch the collector at work with -Xlog:gc — again, as a terminal run:

$ java -Xlog:gc Main
[0.005s][info][gc] Using G1
[0.021s][info][gc] GC(0) Pause Young (Normal) (G1 Evacuation Pause) 48M->1M(516M) 0.777ms
[0.034s][info][gc] GC(1) Pause Young (Normal) (G1 Evacuation Pause) 240M->1M(516M) 0.467ms
[0.042s][info][gc] GC(2) Pause Young (Normal) (G1 Evacuation Pause) 300M->1M(516M) 0.479ms
...
allocated 2000 MB of garbage

Output (illustrative excerpt — real captured run on JDK 25, a 10-core machine; counts, sizes and pause times vary per run):

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

Analysis. The program allocated 2000 MB, but each array became garbage immediately, so the GC reclaimed them in many tiny pauses. Here's how to read one line:

• G1 ran a Young collection.
• It shrank the heap's used space from 300M to 1M, because almost all of it was garbage.
• The heap was 516M in total, and the pause took 0.479 ms.

The heap never grew anywhere near 2 GB, because the collector kept recycling the same space.

G1 is the default only "on server-class machines, Serial Collector otherwise". A machine counts as server-class when the JVM "detects two or more processors and physical memory larger than or equal to 1792 MB" [8]. Tell the same JVM it has only one processor, and it picks Serial:

$ java -Xlog:gc -XX:ActiveProcessorCount=1 Main
[0.005s][info][gc] Using Serial
[0.030s][info][gc] GC(0) Pause Young (Allocation Failure) 137M->1M(494M) 0.250ms

Intuition. Mechanism. The heap is split into generations. New objects go into the young generation, which fills up and gets collected quickly; objects that survive are promoted to the old generation. Since most objects die young, young collections touch little live data, and they're fast. -Xmx and -Xms size the heap, and flags such as -XX:+UseZGC select a different 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 you hit OutOfMemoryError. This program needs a small heap, -Xmx64m, to fail quickly, so it's a terminal run:

// requires: the JVM flag -Xmx64m, so the leak fills a small heap in a moment
import java.util.ArrayList;
import java.util.List;
 
public class Main {
    static final List<byte[]> cache = new ArrayList<>();   // lives as long as the class
 
    public static void main(String[] args) {
        try {
            while (true) cache.add(new byte[64 * 1024]);     // every array stays reachable
        } catch (OutOfMemoryError e) {
            int mb = cache.size() / 16;
            cache.clear();                                   // drop the references: now it is garbage
            System.out.println("OutOfMemoryError: " + e.getMessage() + ", after caching about " + mb + " MB");
        }
    }
}

Output (real captured run on JDK 25, java -Xmx64m Main; three runs printed the same line):

OutOfMemoryError: Java heap space, after caching about 58 MB

Compare it with the §5 garbage program: that one allocated 2000 MB and never ran out, because nothing held onto its arrays. This one kept every array in cache, and ran out after about 58 MB of a 64 MB heap. The GC frees what's unreachable, and a live reference defeats it.

6. Mental-model summary

7. Gotcha checklist

✅ Check yourself

One check per objective. Answer before you open anything.

📚 Sources

1. The Java Language Specification, Java SE 25, §8.3.1.4 "volatile Fields" — https://docs.oracle.com/javase/specs/jls/se25/html/jls-8.html#jls-8.3.1.4
2. The Java Language Specification, Java SE 25, §17.3 "Sleep and Yield" (the this.done loop the compiler may read once) — https://docs.oracle.com/javase/specs/jls/se25/html/jls-17.html#jls-17.3
3. The Java Language Specification, Java SE 25, §17.4.5 "Happens-before Order" — https://docs.oracle.com/javase/specs/jls/se25/html/jls-17.html#jls-17.4.5
4. The Java Language Specification, Java SE 25, §17.5 "final Field Semantics" — https://docs.oracle.com/javase/specs/jls/se25/html/jls-17.html#jls-17.5
5. The Java Language Specification, Java SE 25, §8.10.3 "Record Members" ("A component field is private, final, and non-static") — https://docs.oracle.com/javase/specs/jls/se25/html/jls-8.html#jls-8.10.3
6. The Java Language Specification, Java SE 25, §12.4.1 "When Initialization Occurs" — https://docs.oracle.com/javase/specs/jls/se25/html/jls-12.html#jls-12.4.1
7. The Java Language Specification, Java SE 25, §12.4.2 "Detailed Initialization Procedure" — https://docs.oracle.com/javase/specs/jls/se25/html/jls-12.html#jls-12.4.2
8. HotSpot Virtual Machine Garbage Collection Tuning Guide, Release 25, "Ergonomics" (G1 on server-class machines, Serial otherwise; "Tiered compiler, using both C1 and C2") — https://docs.oracle.com/en/java/javase/25/gctuning/ergonomics1.html
9. The java command, JDK 25 documentation (-XX:+PrintCompilation, -Xlog) — https://docs.oracle.com/en/java/javase/25/docs/specs/man/java.html
10. OpenJDK 25 source, src/hotspot/share/compiler/compilerDefinitions.hpp (enum CompLevel) — https://github.com/openjdk/jdk25u/blob/master/src/hotspot/share/compiler/compilerDefinitions.hpp
11. OpenJDK Code Tools, JMH (Java Microbenchmark Harness) — https://github.com/openjdk/jmh
12. HotSpot Virtual Machine Garbage Collection Tuning Guide, Release 25, "Garbage Collector Implementation" (the weak generational hypothesis) — https://docs.oracle.com/en/java/javase/25/gctuning/garbage-collector-implementation1.html
13. The Java Language Specification, Java SE 25, §12.6.1 "Implementing Finalization" (the definition of a reachable object) — https://docs.oracle.com/javase/specs/jls/se25/html/jls-12.html#jls-12.6.1

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.