Double-Checked Locking in Java — The Pattern, the Bug, and the Fix

Double-checked locking is a lazy-initialization optimization with a famous historical bug.

The pattern

• Check instance == null without locking (fast path)
• If null, acquire lock, check again, then construct
• Goal: avoid locking on every call after the instance exists

Why it was broken pre-Java 5

• instance = new Singleton() is not atomic
• JVM can reorder: allocate → assign reference → run constructor
• Or: allocate → run constructor → assign reference
• Before Java 5's JMM, either order was legal
• Another thread doing the unsynchronized first check could see a non-null reference with uninitialized fields
• Intermittent NPEs / garbage data — the classic production-only bug

The Java 5+ fix — volatile

• Declare private static volatile Singleton instance;
• volatile establishes happens-before between the write to instance and any read
• Constructor's field writes are guaranteed visible to anyone reading the reference
• Reordering no longer allowed
• Use a local variable inside the method to avoid re-reading volatile (performance)

Without volatile, DCL is still broken on Java 21

• The memory model guarantee is specifically tied to volatile semantics
• No amount of synchronized keyword on one side fixes the unsynchronized read

Better alternatives for singletons

1. Initialization-on-demand holder idiom — most senior Java engineers' favorite:

• Private static nested class holding the instance
• JVM class initialization is thread-safe and lazy
• No volatile, no synchronized, no boilerplate
• Downside: can't pass constructor arguments

2. Enum singleton — Joshua Bloch's recommended default:

• public enum Singleton { INSTANCE; }
• Thread-safe, serialization-safe, reflection-safe
• Zero boilerplate
• Can't subclass, can't easily refactor out of singleton

When DCL is still correct

• Lazy instance fields (not statics) where construction needs this.config
• Hand-rolling ConcurrentHashMap.computeIfAbsent for per-key caching
• Guava's `Suppliers.memoize` encapsulates DCL as a library utility — prefer over hand-rolling

Decision guide

• Simple singleton, no args → enum
• Simple singleton, want class-based → holder idiom
• Lazy instance field, per-instance args → DCL with volatile
• Per-key cached value → ConcurrentHashMap.computeIfAbsent

Performance reality check

• DCL's advantage over plain synchronized getInstance() is real but only matters at millions-per-second call rates
• For 99% of application code, synchronized is fine
• Don't DCL-ify code prematurely

Recommendation: For modern Java singletons, default to enum for the simplest case or initialization-on-demand holder idiom when you need a class-based form — both are simpler and safer than DCL. Reserve DCL with volatile for lazy instance fields that genuinely need constructor arguments and are on a hot enough path to justify the complexity. Never write DCL without volatile — it's still broken in Java 21. And when in doubt, use library helpers like Guava's `Suppliers.memoize` so the pattern lives in one well-tested place rather than scattered across your codebase.