JMM Safe Publication — Interview Questions
Reviewed by Gurusankar M.
⚡ Short Answer
The JMM defines happens-before edges that guarantee one thread sees another's writes. Beyond volatile and locks, 'safe publication' is the practical rule: an object is safely published if you share it via a volatile/final field, a static initializer, or a concurrent collection — otherwise another thread may see a partially-constructed object. final fields get a special freeze at the end of the constructor, which is what makes immutable objects safe to share without synchronization.
☕Coffee Chat Question
Concept Made Simple
“How do you reason about safe publication and reordering with the Java Memory Model in lock-free code?”
🧠Mind Map Answer
Remember It Faster
Without a happens-before edge, a write in thread A may never become visible to thread B, and instructions can be reordered. Correctness in lock-free code = making sure every read is reachable from the matching write through a happens-before chain.
Classic trap: double-checked locking is only correct if the field is volatile — otherwise a thread can see a non-null but not-yet-constructed instance. The volatile read/write supplies the missing happens-before edge.
Key takeaway: immutability + final fields is the cheapest correct concurrency. If a field is written once and shared, make it final or volatile — never plain.
⌨️Hands-on Keyboard
Learn by Doing
class Holder {
// volatile is REQUIRED for correct double-checked locking
private static volatile Config instance;
static Config get() {
Config c = instance; // 1 volatile read
if (c == null) {
synchronized (Holder.class) {
c = instance;
if (c == null) instance = c = new Config(); // safe publish
}
}
return c;
}
}🔥What If?
Think Beyond the Expected
Why can another thread see a non-null but half-built object without volatile?
Because object construction (allocate, run constructor, assign reference) can be reordered so the reference is visible before the constructor's writes are. A second thread reads the non-null reference and then reads uninitialised/default fields. Marking the field volatile inserts a happens-before edge that forbids that reordering — the reference can't be published until the constructor's writes are complete.
😂Real World
This is the invisible bug behind 'it works 99.9% of the time, then a field is randomly null under load on a many-core box.' Framework internals (lazy singletons, caches, event buses) live and die by safe publication — which is why libraries lean on volatile, final, and java.util.concurrent instead of hand-rolled flags.
🎯Interviewer's Expectation
Keywords they're listening for:
⚠️Common Mistakes
- ✗Double-checked locking without a volatile field
- ✗Publishing 'this' from a constructor (escapes half-built)
- ✗Assuming a normal write is eventually visible
✅Best Practices
- ✓Prefer immutable objects with final fields
- ✓Publish shared state via volatile, final, or concurrent collections
- ✓Reach for java.util.concurrent before hand-rolled sync
🔁Follow-up Questions
- 1What exactly does the final-field freeze guarantee?
- 2How do VarHandle acquire/release modes relate to happens-before?
- 3Why is a plain boolean 'stop' flag broken?
🧩Related Technologies
Continue Learning with AI
Take this question deeper with your favourite AI assistant. Pick a depth, copy the prompt, or open it directly — AI is your learning companion, not a shortcut.
Plain-language foundations
I'm preparing for a software engineering interview and want to understand this from scratch, as a beginner. Topic: Memory Model (Advanced Java) Interview question: "How do you reason about safe publication and reordering with the Java Memory Model in lock-free code?" Please: 1. Explain the core idea in simple, plain language, using an everyday analogy. 2. Define any technical terms you use. 3. Walk through one small, concrete example. 4. Finish with a single sentence I can easily remember. Keep the tone friendly and assume I'm new to this topic.
Was this answer helpful?
⭐ Featured Products
Support our platform by exploring our recommended products.
As an Amazon affiliate, purchases through these links may earn us a small commission — at no extra cost to you. It helps keep Full Stack Interview Guru free.