HardExperience level: 8-15 years2 min read

JMM Safe Publication — Interview Questions

Reviewed by Gurusankar M.

Asked inGoogleAmazonMicrosoftNetflix
#jmm#happens-before#safe publication#volatile#final fields
Report issue

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.

On this page

Concept Made Simple

Coffee Chat Question

“How do you reason about safe publication and reordering with the Java Memory Model in lock-free code?”

Remember It Faster

Mind Map Answer

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.

volatile write→read
establishes happens-before
final fields
frozen at constructor end → safe to publish
Safe publication
volatile / final / static init / concurrent map
Danger
publishing 'this' or a ref via a plain field

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.

Learn by Doing

Hands-on Keyboard

java
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;
    }
}

Think Beyond the Expected

What If?

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:

  • happens-before edges
  • safe publication rules
  • final-field freeze semantics
  • volatile fixes double-checked locking
  • prefer immutability

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

  1. What exactly does the final-field freeze guarantee?
  2. How do VarHandle acquire/release modes relate to happens-before?
  3. Why is a plain boolean 'stop' flag broken?

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.
Open inChatGPTGeminiClaude

Was this answer helpful?

Affiliate links

Tools for Your Developer Workspace

Equipment for a comfortable, productive setup.

As an Amazon Associate I earn from qualifying purchases.