Engineering Atlas by Abhishek Goyal
Course contents

Happens-before

What happens-before really promises (visibility and ordering, not clock time), every rule from JLS 17.4.5, piggybacking through transitivity, data races and DRF-SC, and the happens-before edges java.util.concurrent documents for queues, executors, futures and latches.

PremiumMust know for interviewsLesson21 min readAdvancedReviewed Oct 2026 · Java 21
On this page
  1. Picture it first: a relay baton
  2. The rules, in plain words
  3. Under the hood: handing a result to the main thread
  4. Piggybacking: one volatile carries everything
  5. What a data race actually is
  6. The java.util.concurrent promises
  7. Approach ladder: hand a fully built result to the main thread
  8. Real world
  9. Advanced: what happens-before does not say
  10. How to say it in the interview

🤝 What is happens-before?

Happens-before is Java's promise about what one thread is guaranteed to see of another thread's work. If action A happens-before action B, then everything A wrote is visible to B, and B can't observe it out of order. It is not about clock time: a write can finish 3 seconds before a read on the wall clock and still be invisible to it, because nothing connected the two. You create the connection on purpose, with a lock, a volatile, start(), join() or a java.util.concurrent handoff.

For this lesson, we'll learn the handful of rules that create happens-before, how they chain together so one volatile can carry a whole object graph, what a data race really is, and the big payoff: if your program has no data races, you get to reason about it as if threads took simple turns. Interviewers love this topic because it's the actual contract under synchronized, volatile and every concurrent collection. Candidates who can say "unlock happens-before the next lock of the same monitor" sound like they understand Java. Candidates who say "volatile flushes the cache" sound like they read a blog post in 2009.

What you’ll learn

  • Explain happens-before as a promise of visibility and ordering between actions, and why it is not wall-clock time
  • List the rules: program order, unlock → later lock of the same monitor, volatile write → later read, Thread.start(), join() / isAlive(), interrupt(), default values and transitivity
  • Use piggybacking to publish plain fields safely through a single volatile write or lock release, and say why the payload must be written first
  • Define a data race in JMM terms and state the DRF-SC guarantee (correctly synchronized programs appear sequentially consistent)
  • Tell a data race from a race condition, and explain why Thread.sleep() creates no happens-before edge
  • Quote the java.util.concurrent Memory Consistency Properties: put → take, submit → task, task → Future.get(), countDown() → await(), map put → get
  • Pick between a naive flag, join() / volatile and a Future, BlockingQueue or CompletableFuture handoff, with the trade-offs
  • Describe how HotSpot implements the edges with fences (x86 TSO vs AArch64 ldar/stlr) without confusing the contract with CPU caches

Premium lesson

Keep reading with the Java Pass

The rest of this lesson is part of Java One-Stop Interview Prep: in-depth explanations, diagrams, model answers and how to say them in the interview.

  • Picture it first: a relay baton
  • The rules, in plain words
  • Under the hood: handing a result to the main thread
  • Piggybacking: one volatile carries everything
  • What a data race actually is
  • The java.util.concurrent promises
  • Approach ladder: hand a fully built result to the main thread
  • Real world
  • Advanced: what happens-before does not say
  • How to say it in the interview
Get the Java Pass Sign in

From ₹299 · one-time payment · No auto-renewal

Practise this topicJava Memory Model: interview questions & scenarios
Further reading (12)