Engineering Atlas by Abhishek Goyal
Course contents

Visibility and reordering

Why one thread can fail to see another thread's write (a stop flag that hangs forever, and the println that hides it), why operations appear reordered (a real two-thread litmus test), the three culprits behind both, and how the Java Memory Model turns them into a contract.

PremiumMust know for interviewsLesson22 min readCoreReviewed Oct 2026 · Java 21
On this page
  1. Picture it first: the notebook and the office whiteboard
  2. Under the hood: the stop flag that never stops
  3. The accidental fix: println and sleep
  4. Reordering: the result that can't happen
  5. The three culprits, and the one contract
  6. Stopping a background worker: from naive to staff
  7. Real world
  8. Advanced: what really happens, and the traps around it
  9. How to say it in the interview

👀 What are visibility and reordering?

Visibility is whether one thread is guaranteed to see a value another thread wrote. Reordering is the compiler or CPU running your statements in a different order than you wrote them, as long as the thread doing the work can't tell. Single-threaded code never notices either one. Add a second thread and you get a loop that never stops even though running was set to false, or a result that "can't happen" showing up 3,088 times in 3 seconds.

For this lesson, we'll start the Java Memory Model topic from zero. You'll watch a real stop flag hang forever, see why a stray println "fixes" it, run the classic two-thread test that catches a CPU reordering your code, and meet the three culprits behind all of it. Interviewers love this one because the bug is three lines long, passes every unit test, and the answer "add volatile" is only the start: the follow-up "why?" is where people who memorised the keyword separate from people who understand the contract.

What you’ll learn

  • Explain visibility and reordering in plain words, and why single-threaded code never notices either
  • Reproduce the stop-flag hang and explain it as the JIT hoisting a field read out of a loop (it stops under -Xint)
  • Explain why adding println or Thread.sleep only hides the bug (JLS 17.3: sleep has no synchronization semantics)
  • Run the x = 1; r1 = y / y = 1; r2 = x litmus test and explain r1 == r2 == 0 with store buffers
  • Name the three culprits (compiler/JIT, CPU, caches as a mental model only) and why coherent caches are not the cause
  • Describe the Java Memory Model as a contract built on happens-before, and list the tools that create edges
  • Stop a background worker the naive, solid and staff way: plain flag, volatile flag, and **owner + volatile + interrupt() + join(timeout)**
  • Contrast x86 TSO with weaker ARM/POWER ordering, and explain what volatile costs and does not do

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: the notebook and the office whiteboard
  • Under the hood: the stop flag that never stops
  • The accidental fix: println and sleep
  • Reordering: the result that can't happen
  • The three culprits, and the one contract
  • Stopping a background worker: from naive to staff
  • Real world
  • Advanced: what really happens, and the traps around it
  • 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 (13)