Explain thread-safe lazy initialization in Java: why is double-checked locking broken without volatile, and how do you fix it?

## The goal: create the instance once, lazily, safely We want to build the single instance only on first use (lazy), but never build two even if many threads call at once (thread-safe). ### Why the naive version is broken ```java if (instance == null) { // (A) instance = new Singleton(); // (B) } return instance; ``` Thread T1 runs (A), sees `null`, and is paused before (B). Thread T2 also runs (A), sees `null`, and creates an instance. T1 resumes and creates **another**. Now there are two - the singleton guarantee is gone. This is a **data race** (two threads access shared state, at least one writing, with no ordering between them). ### Fix attempt: synchronize the whole method ```java public static synchronized Singleton getInstance() { if (instance == null) instance = new Singleton(); return instance; } ``` Correct, but **every** call now acquires a lock even long after the instance exists - needless contention on a hot path. ### Double-checked locking (DCL) The idea: only lock when the instance might still be null. ```java private static Singleton instance; // (still buggy - see below) public static Singleton getInstance() { if (instance == null) { // 1st check (no lock) synchronized (Singleton.class) { if (instance == null) { // 2nd check (locked) instance = new Singleton(); } } } return instance; } ``` Once `instance` is set, the first check passes and we skip the lock - fast. So why is this still wrong? ### The unsafe-publication bug `instance = new Singleton()` is **not a single step**. Roughly it is: (a) allocate memory, (b) run the constructor to initialize the object's fields, (c) assign the reference to `instance`. The Java Memory Model permits the compiler/CPU to **reorder** (b) and (c) - the reference can become non-null **before** the constructor's field writes are visible to other threads. Now another thread runs the first check (outside the lock), sees `instance != null`, skips the synchronized block, and returns a reference to an object whose fields are still default/garbage. This is an **unsafe publication** - a reference escaped before construction finished. The bug is intermittent, CPU/JIT-dependent, and brutal to debug. ### The fix: volatile ```java private static volatile Singleton instance; ``` `volatile` does two things relevant here: - A **volatile write** (assigning `instance`) has **release** semantics: all writes the thread made before it (the constructor's field writes) are flushed and ordered before the volatile write becomes visible. - A **volatile read** (the first check) has **acquire** semantics: it sees those prior writes. Together they create a **happens-before** edge: any thread that reads a non-null `instance` is guaranteed to see a **fully constructed** object. A reader now sees either `null` or a complete object - never a half-built one. `volatile` also forbids the reorder that caused the bug. (Note: before Java 5 the memory model was too weak for even volatile DCL to work; on Java 5+ it is correct.) ### The cleaner alternative: holder idiom ```java private static class Holder { static final Singleton INSTANCE = new Singleton(); } public static Singleton getInstance() { return Holder.INSTANCE; } ``` The JVM guarantees **class initialization runs exactly once and is thread-safe** (it holds an internal lock during init). `Holder` is not loaded until `getInstance()` first reads `Holder.INSTANCE`, so creation is lazy. No `volatile`, no `synchronized`, no DCL subtleties - just the language guarantee. For most cases this is the idiom to reach for; DCL is mainly relevant when you must lazily initialize a *field* of an existing object (not a fresh class) and want to understand the memory model. ### Summary - Naive lazy init: data race -> multiple instances. - Synchronized method: correct but slow on every call. - DCL without volatile: broken by reordering / unsafe publication. - DCL with volatile: correct on Java 5+. - Holder idiom: simplest correct lazy singleton; preferred.