What is double-checked locking, why was it broken before Java 5, and how does volatile fix it?

## The goal We want a lazily-built, thread-safe value, but acquiring a lock on **every** read is wasteful once the value exists. **Double-checked locking (DCL)** tries to lock only on the rare path where the value still needs building. ## The shape ```java private volatile Foo instance; // volatile is essential (see below) public Foo getInstance() { Foo result = instance; // 1st check, no lock (fast path) if (result == null) { synchronized (this) { result = instance; // 2nd check, under lock if (result == null) { result = new Foo(); instance = result; // publish } } } return result; } ``` - **First check** (no lock): if `instance` is already set, return it immediately — no synchronization cost on the common path. - **Lock + second check**: only threads that saw `null` enter the `synchronized` block. Inside, they re-check because another thread may have built it while they waited for the lock. Hence *double*-checked. - The local `result` variable is a minor optimization that reads the volatile field once. ## Why it was broken before Java 5 To understand the bug you need two ideas: 1. **`new Foo()` is not atomic.** It compiles to roughly: (a) allocate memory, (b) run the constructor to initialize fields, (c) assign the reference to `instance`. 2. **Reordering.** The Java compiler, JIT, and CPU are allowed to reorder operations as long as a **single thread** can't tell. Nothing stops step (c) — publishing the reference — from being moved **before** step (b) finishes. So a thread building the object could publish a **non-null reference to a not-yet-fully-constructed object**. A second thread on the lock-free fast path sees `instance != null`, skips the lock, and returns an object whose fields are still defaults/garbage. Worse, even with proper ordering, the old (pre-JSR-133) memory model gave **no visibility guarantee**: a reader might see the reference but stale field values. Because the bug is timing- and JIT-dependent, it passes tests and explodes in production. This is why DCL was famously declared 'broken' for years. ## How Java 5's memory model + volatile fixes it Java 5 adopted the **JSR-133** memory model, which strengthened `volatile`. A `volatile` field now has **acquire/release** semantics: - **Release on write**: when a thread writes the volatile `instance`, all memory writes it did **before** that (including the constructor's field initializations) are flushed and ordered **before** the volatile write. The publish can't 'jump ahead' of the construction. - **Acquire on read**: when another thread reads the non-null volatile `instance`, it is guaranteed to **also see everything written before** the release. This creates a **happens-before** edge between 'construct + publish' and 'read'. Result: any thread that sees a non-null `instance` sees a **fully constructed** object. `volatile` both forbids the harmful reordering and guarantees visibility. Without `volatile`, DCL is still wrong on Java 5+. ## Caveats and alternatives - The field **must** be `volatile` — a common interview trap is to write DCL without it. - DCL is verbose and easy to get subtly wrong. For a plain singleton, the **initialization-on-demand holder idiom** is simpler and equally correct. For per-key values, `ConcurrentHashMap.computeIfAbsent`; for a parameter-free deferred computation, a memoizing `Supplier`. DCL earns its keep mainly for **lazy instance fields** or values that need runtime parameters, where the holder idiom can't be used. - For primitives/immutable values you can sometimes drop the lock entirely; for an effectively-immutable object even a benign race (building twice) may be acceptable, but DCL with `volatile` is the safe default.