What is the happens-before relationship?

The Answer

Say this in the room. 45 seconds.

• happens-before is a guarantee about visibility, not a statement about time. "Earlier on the clock" means nothing across threads.
• If A happens-before B, then everything written before A is visible to B — not just the field you were thinking about.
• With no edge between a write in one thread and a read in another, the read is not guaranteed to see the write. Ever. Not "usually sees it late".
• The edges you actually use: program order within a thread, monitor release/acquire, volatile write/read, Thread.start(), Thread.join(), latches and futures, and any java.util.concurrent handoff.
• It is transitive: A → B and B → C gives you A → C. Almost all real reasoning is chaining edges.
• The practical payoff is the reverse of the instinct: if a value crosses an edge, a plain field is fine. Most volatile in real codebases is unnecessary, and the ones that matter are missing.

Understand It

It is a guarantee, not a clock

"Happens-before" is the worst-named concept in Java. It says nothing about which line executes first in wall-clock time. It is a relation between two actions that, when it holds, obliges the JVM to make the first one's writes visible to the second.

Turn it around, because this is the half that matters: where the relation does not hold, nothing is guaranteed. A thread can write a field and another thread can read that field a full second later and legally see the old value — because without an edge, the compiler may keep the value in a register, the CPU may not flush the store buffer, and neither is required to do anything about it.

This is why "I added a sleep and it worked" is not a fix. Time is not an edge.

The edges

That is the whole practical list. Everything else is these chained together.

Two edges you already use without knowing

Thread.start() and Thread.join() are edges, which means plain fields cross them safely. No volatile, no lock, nothing:

Config config = new Config();
config.timeoutMillis = 250;
config.endpoint = "https://api.internal/v2";

Thread worker = new Thread(() -> {
    System.out.println("  worker sees timeout  : " + config.timeoutMillis);
    System.out.println("  worker sees endpoint : " + config.endpoint);
    config.result = "ok";
});
worker.start();
worker.join();
System.out.println("  main sees result     : " + config.result);

  worker sees timeout  : 250
  worker sees endpoint : https://api.internal/v2
  main sees result     : ok

Every field there is a plain field. The setup is visible to the worker because it happened before start(). The worker's write is visible to main because it happened before join() returned. Adding volatile to any of them would change nothing except the reader's confidence in whoever wrote it.

Transitivity is where the work happens

The rule that makes this usable: if A happens-before B and B happens-before C, then A happens-before C. So a single edge can carry an unlimited amount of unrelated state across with it.

Here the producer writes two plain fields, then counts down a latch. The consumer awaits the latch, then reads them:

Report report = new Report();
CountDownLatch ready = new CountDownLatch(1);

Thread producer = thread(() -> {
    report.rows = List.of("alpha", "beta", "gamma");
    report.total = 3;
    ready.countDown();
});
Thread consumer = thread(() -> {
    ready.await();
    System.out.println("  consumer sees rows  : " + report.rows);
    System.out.println("  consumer sees total : " + report.total);
});
producer.join();
consumer.join();

  consumer sees rows  : [alpha, beta, gamma]
  consumer sees total : 3

Chain it: the two writes happen-before countDown() by program order; countDown() happens-before await() returning; await() returning happens-before the reads by program order. So the writes happen-before the reads.

The latch is not protecting rows and total. It does not know they exist. It provides one edge, and transitivity carries everything written before it.

The same is true of every executor handoff

submit and Future.get() are an edge in each direction, which is why a pool task can write plain fields and the submitting thread can read them:

ExecutorService pool = Executors.newFixedThreadPool(2);
Batch batch = new Batch();

Future<Integer> f = pool.submit(() -> {
    batch.processed = 500;
    return batch.processed;
});

System.out.println("  future returned : " + f.get());
System.out.println("  main sees field : " + batch.processed);
pool.shutdown();
System.out.println("  pool terminated : " + pool.awaitTermination(5, TimeUnit.SECONDS));

  future returned : 500
  main sees field : 500
  pool terminated : true

This generalises: anything in java.util.concurrent that hands work or data between threads gives you an edge. A BlockingQueue put happens-before the matching take. That is why a producer can build an object, put it on a queue, and the consumer sees it fully built with no synchronization of its own.

Immutability is the edge you get for free

A final field assigned in a constructor is guaranteed visible, fully initialised, to any thread that later sees the reference — with no volatile, no lock, no edge of your own. That is the freeze action at the end of the constructor, and it is the single most useful guarantee in the memory model.

It is also why the fix to almost every publication bug is the same shape: don't mutate shared state, replace it. Build a complete immutable object, publish the reference with one write, and readers get all of it or none of it.

The one condition people miss: the guarantee covers the object as the constructor left it. If the constructor leaks this — registers a listener, starts a thread, passes itself to something — another thread can reach the object before the freeze, and the guarantee is gone.

What this page cannot show you

Every block above proves an edge working. None of them show an edge missing, and that is deliberate: a missing edge produces a bug that depends on the JIT's decisions, the core count, and the CPU's memory model. On x86 it may never appear. On ARM it may appear immediately — which is why a service that ran for years on Intel started failing when it moved to Graviton.

So there is no honest way to print the failure here. Which is the point of the entry: this is the one area of Java where running the code is not how you establish correctness. You establish it by naming the edge. If you cannot name one, there isn't one.

The real tool for the other direction is jcstress, which runs billions of iterations across specially generated interleavings to expose exactly these bugs. It exists because ordinary testing cannot find them.

Interviewer's Next Move

The question after the question. This is what the round is actually testing.

1. "What is happens-before?" A visibility guarantee between two actions: if A happens-before B, everything written before A is visible to B. It says nothing about wall-clock time, and where the relation is absent there is no guarantee at all.

2. "Name the edges you actually use." Program order within a thread; releasing and acquiring the same monitor; a volatile write and its later reads; Thread.start() and Thread.join(); final fields at the end of a constructor; and every java.util.concurrent handoff — latches, futures, blocking queues.

3. "Why does transitivity matter?" Because one edge carries everything written before it. A latch does not know which fields you wrote; chaining program order into the latch edge and back out is what makes plain fields safe across it.

4. "Do I need volatile on a field written before Thread.start()?" No. start() is an edge, so everything before it is visible in the new thread. Most volatile in real code is like this — unnecessary where it appears and missing where it matters.

5. "What does final guarantee?" That a field assigned in the constructor is visible, fully initialised, to any thread that sees the reference, with no synchronization. The exception is a constructor that leaks this, which lets another thread reach the object before the freeze.

6. "I added a sleep and the bug went away." Nothing was fixed. Time is not a happens-before edge. The sleep changed the timing enough to hide it on this machine, and it will return on hardware with a weaker memory model.

7. "How would you prove code is free of a visibility bug?" Not by running it. Name the edge between the write and the read; if you cannot, there isn't one. jcstress exists for the empirical direction precisely because ordinary tests cannot reach these interleavings.

8. "How do you publish a configuration object safely?" Make it immutable with final fields, build the replacement completely, and assign it to a volatile reference in one write. Readers take a single read into a local and use that — two reads can straddle a reload.

Code traps

Trap A — predict before you run:

class Worker implements Runnable {
    private boolean done = false;

    public void run() {
        while (!done) { process(); }
    }

    public void finish() { done = true; }
}

Trap B:

class Session {
    private final String user;

    Session(String user, Registry registry) {
        registry.register(this);        // before the field is assigned
        this.user = user;
    }
}

Trap C:

private volatile Settings settings;

public String describe() {
    return settings.endpoint + " (" + settings.timeoutMillis + "ms)";
}

Common wrong answers

Check Yourself

Q1. A field is written by main before thread.start() and read inside the thread. Does it need volatile?

Q2. A producer writes five plain fields, then calls latch.countDown(). A consumer returns from await() and reads all five. Are they visible, and why?

Q3. Settings is immutable and its reference is volatile. A method reads settings.endpoint and settings.timeoutMillis on separate lines. What can go wrong?

Practice