volatile

For this lesson, we'll start with a program that hangs forever because one keyword is missing, find out who really causes the hang (spoiler: it's the JIT compiler, not a "stale CPU cache"), and then pin down exactly what volatile promises and what it doesn't. Interviewers love this topic because nearly everyone has heard "volatile means read from main memory", and almost nobody can explain why volatile int count; count++ still loses updates. That gap is where interviews are won.

01Picture it first: the sticky note and the whiteboard

Imagine an office with a big whiteboard that says running = true. A worker copies that onto a sticky note on his monitor, because glancing at the note is faster than turning around. Later, the manager walks up and changes the whiteboard to running = false. The worker keeps glancing at his sticky note. He never stops.

volatile is the office rule "no sticky notes for this one". Every time you check, you look at the whiteboard.

Here's the thing, though. This is a mental model, not how the silicon works. Modern CPU caches are coherent: hardware protocols (MESI and friends) make sure two cores don't keep disagreeing about the same cache line for long. The "sticky note" in real life is usually a CPU register, filled by the JIT compiler, plus a few hardware tricks like store buffers. We'll catch the JIT doing it in a minute. The actual contract you program against is the Java Memory Model (JLS chapter 17.4), which talks about happens-before, not caches.

02Under the hood: a program that never ends

This is the program I use to show it live. Notice the watchdog: the workers are daemon threads and main only waits 2 seconds, so a stuck worker can't hang your terminal.

public class StopFlag {
    static boolean plainRunning = true;             // no volatile
    static volatile boolean volatileRunning = true; // volatile

    public static void main(String[] args) throws InterruptedException {
        Thread plain = new Thread(() -> {
            long spins = 0;
            while (plainRunning) { spins++; }       // tight loop, no method calls
            System.out.println("plain worker saw the flag after " + spins + " spins");
        });
        plain.setDaemon(true);                      // so a stuck worker can't keep the JVM alive
        plain.start();
        Thread.sleep(100);
        plainRunning = false;
        System.out.println("main: set plainRunning = false");
        plain.join(2_000);                          // watchdog: wait at most 2 s
        System.out.println(plain.isAlive() ? "plain worker: STILL RUNNING after 2 s" : "plain worker: stopped");

        Thread vol = new Thread(() -> {
            long spins = 0;
            while (volatileRunning) { spins++; }
            System.out.println("volatile worker saw the flag after " + spins + " spins");
        });
        vol.setDaemon(true);
        vol.start();
        Thread.sleep(100);
        volatileRunning = false;
        System.out.println("main: set volatileRunning = false");
        vol.join(2_000);
        System.out.println(vol.isAlive() ? "volatile worker: STILL RUNNING after 2 s" : "volatile worker: stopped");
    }
}

On my Apple M4 Pro with JDK 26, java StopFlag.java printed this in three runs out of three (the spin count changes every run):

main: set plainRunning = false
plain worker: STILL RUNNING after 2 s
main: set volatileRunning = false
volatile worker saw the flag after 368451599 spins
volatile worker: stopped

The plain worker never saw false. Not after 100 ms, not after 2 seconds, not ever. Same code, one keyword different.

Who's really holding the sticky note?

Now the interesting part. I ran the exact same file three more ways:

java -Xint StopFlag.java                    -> plain worker saw the flag after 27447891 spins
java -XX:TieredStopAtLevel=1 StopFlag.java  -> plain worker saw the flag after 391571875 spins
JDK 21, four runs                           -> hung, stopped, hung, stopped

With -Xint (interpreter only) the plain worker stops. With TieredStopAtLevel=1 (only the quick C1 compiler) it stops too. Same CPU, same caches. The only thing that changed is which compiler ran the loop, so the caches can't be the culprit. It's the optimising C2 compiler.

Here's what C2 is allowed to do. Inside that loop, nothing writes plainRunning, and the field isn't volatile, so as far as the JMM is concerned no other thread needs to be considered. C2 reads the field once, keeps it in a register and turns your loop into "if it was true, loop forever". This is called hoisting a read out of a loop, and it's a perfectly legal optimisation.

Notice three things:

1. The bug depends on timing. On JDK 21 it hung only half the time, because it depends on whether C2 compiled the loop before or after the flag flipped. "It works on my machine" is the most dangerous output a concurrency bug can give you.
2. A println or Thread.sleep inside the loop often "fixes" it by accident. The call makes it hard for C2 to prove the field didn't change, so it re-reads. That's luck, not a guarantee. Remove the logging in a refactor and the hang comes back.
3. volatile is the guarantee. A volatile read must happen on every iteration, and the JMM promises it will eventually see the write.

03What volatile actually guarantees

There are exactly three promises. Learn them as a list; interviewers check each one.

The second row is the one people forget, and it's the most useful. Picture a courier who seals a box and then rings the doorbell. If you hear the bell, you know the box is on the doorstep. The bell is the volatile write; the box is all the plain data written before it.

In code, that's the whole trick behind safe hand-offs:

int data;                 // plain field
volatile boolean ready;   // the doorbell

// writer thread
data = 42;
ready = true;             // volatile write: publishes data too

// reader thread
if (ready) {              // volatile read that sees true
    System.out.println(data);  // guaranteed to print 42, never 0
}

Without volatile on ready, the reader could see ready == true and still print 0, because the compiler or CPU may reorder the two writes. We dig into that reordering in Visibility and reordering and the rule itself in Happens-before.

About that third row: the JLS lets a JVM split a plain 64-bit long or double write into two 32-bit halves, so another thread could see the top half of one value and the bottom half of another. That's called tearing. Every mainstream 64-bit JVM today writes them in one go, so you'll struggle to reproduce it, but the spec only guarantees it with volatile. References and all other primitives never tear.

04What volatile does NOT do: count++

This is the bit that trips people up. count++ looks like one operation, but it's three: read the value, add one, write it back. volatile makes each read and each write visible. It does nothing to stop another thread sneaking in between them.

import java.util.concurrent.atomic.AtomicInteger;

public class VolatileCounter {
    static volatile int volatileCount = 0;
    static final AtomicInteger atomicCount = new AtomicInteger();

    public static void main(String[] args) throws InterruptedException {
        int threads = 4, perThread = 1_000_000;
        Thread[] ts = new Thread[threads];
        for (int i = 0; i < threads; i++) {
            ts[i] = new Thread(() -> {
                for (int j = 0; j < perThread; j++) {
                    volatileCount++;                 // read, add 1, write: three steps
                    atomicCount.incrementAndGet();   // one atomic step
                }
            });
            ts[i].start();
        }
        for (Thread t : ts) t.join();
        int expected = threads * perThread;
        System.out.printf("expected      %,d%n", expected);
        System.out.printf("volatile int  %,d  (lost %,d)%n", volatileCount, expected - volatileCount);
        System.out.printf("AtomicInteger %,d%n", atomicCount.get());
    }
}

Three runs, three different wrong answers for the volatile counter:

expected      4,000,000
volatile int  2,154,771  (lost 1,845,229)
AtomicInteger 4,000,000

volatile int  2,172,599  (lost 1,827,401)
volatile int  2,079,389  (lost 1,920,611)

Almost half the increments vanished, on a field marked volatile. Here's how one of them disappears.

The fix is an atomic read-modify-write: AtomicInteger.incrementAndGet(), LongAdder for very hot counters, or a lock. We build those up in Atomic classes. The same trap catches check-then-act code like if (instance == null) instance = new X(); on a volatile field: two threads can both pass the check.

Rule of thumb: volatile is safe when each write doesn't depend on the current value, or when only one thread ever writes.

05When volatile is exactly the right tool

Here are the four patterns I'd reach for, and the reason each one is safe.

1. Stop and status flags. volatile boolean running, volatile State state. One write, many reads, and the new value doesn't depend on the old one. (For stopping threads that block in sleep or I/O, pair it with interrupts.)
2. One writer, many readers. A single thread updates volatile long lastHeartbeatMillis; monitoring threads read it. With one writer, there's no read-modify-write race.
3. Publishing an immutable snapshot. Build a new immutable object, then assign it to a volatile reference in one write. Readers get either the whole old object or the whole new one. More on this in the ladder below.
4. The volatile in double-checked locking. The lazy-singleton idiom only works if the instance field is volatile, because otherwise another thread can see the reference before the constructor's writes. That story gets its own lesson: Safe publication and double-checked locking.

06The approach ladder: one config, 50 readers

Here's a problem you'll hit in real services. One background thread reloads a config every 30 seconds (say maxConnections and timeoutMs, which must stay consistent). 50 request threads read it on every request. Let's solve this the way you'd grow into it in an interview.

Here's the staff version as a runnable test, racing it against two separate volatile fields:

import java.util.concurrent.atomic.LongAdder;

public class ConfigSnapshot {
    // Two settings that must always match: timeoutMs == maxConns * 10.
    record Config(int maxConns, int timeoutMs) { }

    static volatile int maxConns = 10, timeoutMs = 100;       // two separate volatile fields
    static volatile Config config = new Config(10, 100);      // one volatile reference to an immutable object

    public static void main(String[] args) throws InterruptedException {
        System.out.println("two volatile fields : " + run(false) + " mixed reads");
        System.out.println("volatile snapshot   : " + run(true) + " mixed reads");
    }

    static long run(boolean snapshot) throws InterruptedException {
        LongAdder mixed = new LongAdder();
        Thread[] readers = new Thread[50];
        long end = System.nanoTime() + 500_000_000L;           // 0.5 s per run
        for (int i = 0; i < readers.length; i++) {
            readers[i] = new Thread(() -> {
                while (System.nanoTime() < end) {
                    int m, t;
                    if (snapshot) { Config c = config; m = c.maxConns(); t = c.timeoutMs(); }
                    else { m = maxConns; t = timeoutMs; }
                    if (t != m * 10) mixed.increment();
                }
            });
            readers[i].start();
        }
        boolean big = false;
        while (System.nanoTime() < end) {                      // one writer flips between two configs
            big = !big;
            int m = big ? 20 : 10;
            if (snapshot) config = new Config(m, m * 10);
            else { maxConns = m; timeoutMs = m * 10; }
        }
        for (Thread r : readers) r.join();
        return mixed.sum();
    }
}

two volatile fields : 23891 mixed reads
volatile snapshot   : 0 mixed reads

two volatile fields : 16725 mixed reads
volatile snapshot   : 0 mixed reads

Notice the reader copies config into a local c once. If it read config.maxConns() and then config.timeoutMs() as two separate volatile reads, it could straddle a swap and mix configs all over again. One read, one snapshot.

My default: start with SOLID if you're unsure, and move to the volatile snapshot when the data is read far more often than it's written. It's the same idea CopyOnWriteArrayList is built on.

07Real world

Two bug shapes I see in code review:

• The stop flag that works in tests. A boolean shutdown without volatile, in a loop that happens to log. Someone removes the log line for performance, C2 hoists the read, and the service hangs on shutdown. Fix: volatile, or AtomicBoolean, or interrupts.
• The "volatile counter". volatile long requestCount; requestCount++ in a metrics class, written by every request thread. The dashboard quietly under-reports. Fix: LongAdder.

08Advanced: fences, CPUs and access modes

How HotSpot implements it: barriers

The JSR-133 Cookbook (Doug Lea) describes four barrier types: LoadLoad, LoadStore, StoreStore and StoreLoad. Conceptually, the JVM puts barriers around volatile accesses like this:

StoreStore   <- earlier writes can't sink below the volatile write
volatile write
StoreLoad    <- the volatile write can't be overtaken by a later volatile read

volatile read
LoadLoad + LoadStore  <- later reads and writes can't float above it

The StoreLoad barrier is the expensive one, because it forces the CPU to drain its store buffer (a small queue where a core parks writes before they reach the cache, so it can keep running). That buffer is also the one place where even x86 reorders: a later load can complete before an earlier store becomes visible.

x86 vs ARM

That last row matters in 2026. Code that "worked for years" on x86 servers can break on ARM (Graviton, Apple Silicon), because x86 was quietly hiding missing volatiles. HotSpot uses lock addl on the stack rather than mfence on x86 because it's usually cheaper; Aleksey Shipilev's write-up "On The Fence With Dependencies" digs into the trade-off.

VarHandle access modes (Java 9+)

Since Java 9, VarHandle lets you pick the strength per access instead of per field. Doug Lea's "Using JDK 9 Memory Order Modes" describes four modes, weakest to strongest:

import java.lang.invoke.MethodHandles;
import java.lang.invoke.VarHandle;

class Mailbox {
    private int data;
    private boolean ready;
    private static final VarHandle READY;
    static {
        try { READY = MethodHandles.lookup().findVarHandle(Mailbox.class, "ready", boolean.class); }
        catch (ReflectiveOperationException e) { throw new ExceptionInInitializerError(e); }
    }
    void put(int d) { data = d; READY.setRelease(this, true); }           // release: publishes data
    Integer take()  { return (boolean) READY.getAcquire(this) ? data : null; } // acquire: sees data
}

Release/acquire skips the StoreLoad fence, so on ARM setRelease is a cheaper store than a full volatile write. The catch: you lose the single total order, which breaks algorithms like Dekker-style "I set my flag, then check yours". Default to plain volatile; reach for weaker modes only with a benchmark and a jcstress test.

volatile vs synchronized vs atomics

09How to say it in the interview

When I ask about volatile, I'm listening for three things. Do you name visibility and ordering (not "reads from main memory")? Do you say, without being prompted, that count++ isn't atomic on a volatile? And can you give a use case where it's genuinely the right tool, ideally the immutable snapshot?

Here's how this might look if you sketch it on the whiteboard: