HardExperience level: 8-15 years1 min read

Why did the double-checked locking singleton need volatile to be correct?

Reviewed by Gurusankar M.

Asked inAmazonMicrosoftGoogle
#double-checked locking#volatile#singleton#safe publication#reordering
Report issue

Short Answer

Object construction isn't atomic: the JIT can publish the reference BEFORE the constructor finishes. Without volatile, a second thread can see a non-null but partially-constructed instance. Marking the field volatile forbids that reordering and ensures safe publication.

On this page

Concept Made Simple

Coffee Chat Question

“Why did the double-checked locking singleton need volatile to be correct?”

Remember It Faster

Mind Map Answer

instance = new Singleton() is really: allocate → construct → assign. Reordering can make the assign visible before construct completes → another thread sees a half-built object. volatile blocks the reorder.

Learn by Doing

Hands-on Keyboard

java
private static volatile Singleton inst; // volatile is essential
static Singleton get() {
    if (inst == null) {
        synchronized (Singleton.class) {
            if (inst == null) inst = new Singleton();
        }
    }
    return inst;
}

Think Beyond the Expected

What If?

Is there a simpler correct lazy singleton that avoids this subtlety?

Yes — the initialization-on-demand holder idiom: a private static holder class whose static field is the instance. The JVM's class-init guarantees lazy, thread-safe, single creation with no locking or volatile. An enum singleton is also safe.

Real World

DCL is a favorite hard interview question because it exposes deep memory-model understanding; in practice teams use the holder idiom or enum, or a DI container, rather than hand-written DCL.

Interviewer's Expectation

Keywords they're listening for:

  • non-atomic construction
  • reordering publishes early
  • volatile prevents partial publication
  • holder idiom / enum alternative

Common Mistakes

  • Omitting volatile on the instance field
  • Hand-rolling DCL instead of using the holder idiom
  • Assuming object construction is atomic

Best Practices

  • Prefer the holder idiom or enum singleton
  • If using DCL, the field MUST be volatile
  • Let a DI framework manage singletons

Follow-up Questions

  1. How does the holder idiom guarantee thread safety?
  2. Why is an enum the most robust singleton?
  3. What changed in the Java 5 memory model to make DCL fixable?

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: Locks (Multithreading)
Interview question: "Why did the double-checked locking singleton need volatile to be correct?"

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.