the java memory model

the picture

you'd think memory is one big shared whiteboard, and every write lands on it the instant it happens, in program order. that's the model in your head, and it has a name: sequential consistency. no real machine works like that, because it would be painfully slow.

instead, every core keeps its own scribbles: values in registers, writes queued in a store buffer waiting to reach the cache, lines sitting in its private cache. on top of that, the JIT freely reorders, merges and deletes memory accesses when the current thread can't tell the difference. "the current thread can't tell" is the key phrase. other threads can.

the memory model is the deal between you and all that machinery: write your program with proper happens-before edges, and everything behaves as if there were one whiteboard. skip them, and you get whatever the hardware and the JIT felt like.

the litmus test

the classic four-line program that breaks everyone's intuition:

int x = 0, y = 0;
 
// thread 1          // thread 2
x = 1;               y = 1;
int r1 = y;          int r2 = x;

this isn't a theoretical curiosity. I ran exactly this test with jcstress (the OpenJDK tool built for testing the memory model) on jdk 25, on an arm mac:

that's not a broken CPU. ARM and x86 both have store buffers, and both allow this particular reordering (a store followed by a load of a different address). ARM allows a lot more than x86 does. the memory model has to work on all of them, so it promises very little for plain fields and lets you ask for more where you need it.

happens-before

the JMM doesn't talk about caches or store buffers at all. it defines one relation between actions, happens-before, and one promise:

if a write happens-before a read of the same variable (and no other write sneaks in), the read sees that write.

program order

within one thread, each action happens-before the next one. so a single thread always sees its own writes, in order.

monitor

an unlock of a monitor happens-before every later lock of that same monitor.

volatile

a write to a volatile field happens-before every later read of that field.

thread start

t.start() happens-before every action in t.

thread end

every action in t happens-before another thread's t.join() returning (or t.isAlive() returning false).

transitivity

if a happens-before b, and b happens-before c, then a happens-before c. this is where all the power is.

(there are a few more: interrupting a thread happens-before it noticing the interrupt, and the default zero of every field happens-before every thread's first action. the full list is JLS §17.4.4 and §17.4.5.)

notice that the volatile edge protects data, which isn't volatile at all. T1's write of data happens-before its volatile write (program order), which happens-before T2's volatile read (volatile rule), which happens-before T2's read of data (program order). transitivity does the rest. this is called piggybacking, and it's how almost every concurrent class in the JDK publishes its state: one volatile or one lock, guarding a pile of plain fields.

the jcstress version of that exact message-passing pattern, again on jdk 25:

volatile: visibility, not atomicity

a volatile field gives you two things: every read sees the latest write (in the happens-before sense), and plain reads and writes can't be moved across it in the dangerous directions. it's the cheapest synchronization java has.

here's the stop flag from effective java item 78, without volatile:

public class StopThread {
    private static boolean stopRequested;
 
    public static void main(String[] args) throws InterruptedException {
        Thread background = new Thread(() -> {
            long i = 0;
            while (!stopRequested) i++;
            System.out.println("stopped after " + i);
        });
        background.start();
        Thread.sleep(1000);
        stopRequested = true;
        System.out.println("main: set stopRequested = true");
    }
}

on jdk 25 on my machine, three runs out of three printed main: set stopRequested = true and then hung forever, the background thread spinning on a core. with -Xint (interpreter only, no JIT) it stopped right away, after about 225 million iterations. so it's not that the write never reaches memory. it's that C2 compiled the loop, saw no happens-before edge that could ever change stopRequested inside it, and read the field once:

// what the JIT is allowed to turn the loop into
if (!stopRequested) {
    while (true) i++;
}

completely legal under the JMM. whether it actually hangs depends on the JIT, the timing and the platform, which is exactly the problem: it might pass every test and hang in prod. one keyword fixes it, and now it behaves the same every time:

static volatile boolean stopRequested;
 
void main() throws InterruptedException {
    Thread background = new Thread(() -> {
        long i = 0;
        while (!stopRequested) i++;
        IO.println("stopped");
    });
    background.start();
    Thread.sleep(1000);
    stopRequested = true;
    background.join();
    IO.println("done");
}

stopped
done

final fields and safe publication

there's one more way to be surprised: seeing an object before it's finished. p = new Point(1, 2) is several steps (allocate, write x, write y, store the reference), and without happens-before, another thread can observe them in a different order.

final fields come with a special guarantee (JLS §17.5): when a constructor finishes, its final fields are frozen, and any thread that gets a reference to the object after that sees the final fields' constructed values, even if the reference was passed through a data race. that's what makes immutable objects like String safe to share without any locking. the one way to break it: let this escape from the constructor (register a listener, start a thread, store this somewhere) before it finishes.

for everything that isn't final, you need to publish safely, which just means: hand over the reference through a happens-before edge.

the most famous unsafe publication is double-checked locking without volatile, which can hand out a half-constructed singleton. it gets its own chapter: singletons and double-checked locking.