A Singleton creates its instance lazily on first call to its accessor. What can go wrong when several threads call that accessor at the same time, and which implementation strategies fix it?

## Two distinct bugs hide in one line of code ``` static getInstance(): if (instance == null) # (A) check instance = new Heavy() # (B) create + assign return instance ``` ### Bug 1 — the check-then-act race (duplicate instances) Thread T1 evaluates (A) and finds `null`. Before T1 reaches (B), the scheduler switches to T2, which also evaluates (A), also finds `null`. Both proceed to construct. You now have **two** instances; the second assignment wins, so the two threads hold *different* objects. Consequences range from harmless (a stateless helper) to severe: two caches that diverge, two connection pools each opening the configured maximum, two ID generators emitting overlapping IDs, a setup side effect (file created, port bound, native library initialised) executed twice. ### Bug 2 — unsafe publication (a half-built object) Even if only one thread constructs, another thread may observe a **non-null reference to an incompletely initialised object**. Constructing an object involves allocating memory, running the constructor's field writes, then storing the reference. Compilers and CPUs are permitted to reorder the reference store *before* the field writes become visible to other threads, as long as the reordering is invisible to the *constructing* thread. A reader that only checks `instance != null` can therefore see the reference and then read default/garbage field values. This is a **memory-model** problem, not a scheduling problem — no amount of retrying makes it go away, and it can be invisible on a strongly-ordered CPU and then appear in production on a weakly-ordered one. ## Strategy 1 — eager (static) initialization Build the instance when the class/module is initialised: ``` class Registry: private static final instance = new Registry() ``` Language runtimes that have a class-initialization phase (JVM, .NET) run it **under an internal lock, exactly once, with a memory barrier at the end**, so both bugs are impossible with no code from you. Cost: the object is built whether or not it is used, at a time you do not fully control, and a failure during construction surfaces as an obscure class-initialization error. ## Strategy 2 — initialization-on-demand holder ``` class Registry: private static class Holder: static final instance = new Registry() static getInstance(): return Holder.instance ``` The nested holder type is only initialised when it is first *referenced*, i.e. on the first `getInstance()` call. You get laziness with the runtime's once-only, safely-published class-initialization guarantee and **zero synchronization on the fast path**. On the JVM this is the textbook answer. It requires a language with lazy, thread-safe type initialization. ## Strategy 3 — a run-once primitive Most modern standard libraries ship one: - `std::call_once` / function-local `static` ("magic statics") in C++11+ - `sync.Once` in Go - `Lazy<T>` (with the thread-safe mode) in .NET - `lazy { }` / `object` in Kotlin, `lazy_static`/`OnceLock` in Rust They encapsulate the lock, guarantee the initialiser runs exactly once, and publish safely. **Prefer these over hand-rolled locking** — they are correct by construction and usually optimised (fast path is a single atomic load). ## Strategy 4 — synchronize the whole accessor ``` static synchronized getInstance(): if (instance == null) instance = new Registry() return instance ``` Correct and trivially reviewable. The downside is that **every** call — not just the first — pays lock acquisition, and under high contention the accessor becomes a serialization point. On modern runtimes with biased/thin locks this is far cheaper than folklore suggests, so measure before rejecting it. ## Strategy 5 — double-checked locking (DCL) ``` static getInstance(): if (instance == null) { # fast path, no lock lock (classLock) { if (instance == null) # re-check under the lock instance = new Registry() } } return instance ``` The *only* thing that makes this correct is declaring the field with the language's ordering annotation — `volatile` in Java/C#, an atomic with acquire/release ordering in C++ — plus reading it into a **local variable** to avoid re-reading. Without that, the outer unlocked read is exactly bug 2. DCL was famously **broken on the JVM before Java 5**, and remains broken in any language whose memory model does not order the store. Modern verdict: DCL is a correct-but-fiddly micro-optimisation; the holder idiom or a run-once primitive is preferred, and reviewers should treat a hand-written DCL as a smell. ## Comparison | Strategy | Lazy? | Fast-path cost | Failure mode if done wrong | |---|---|---|---| | Eager static | No | None | Startup cost, obscure init errors | | Holder idiom | Yes | None | Needs runtime with lazy type init | | Run-once primitive | Yes | One atomic load | Choosing a non-thread-safe mode | | Synchronized accessor | Yes | Lock every call | Contention, not correctness | | Double-checked locking | Yes | One volatile read | Torn/half-built object if the field isn't volatile | ## Edge cases worth naming - **Reentrancy / initialization deadlock**: if the constructor (directly or transitively) calls back into `getInstance()`, a synchronized accessor deadlocks or a holder-based one returns a partially built object. Keep constructors dependency-free. - **Exceptions during initialization**: with class-init-based approaches the type is marked erroneous and every later access fails with a different, confusing error; with a locked accessor the field stays null and the next caller retries — which may be better or worse depending on whether the failure is transient. - **Once-only side effects**: if construction binds a port or writes a file, a duplicate instance is not just wasteful, it is a hard failure. That is the case where getting this right actually matters. - **Uniqueness ends at the process boundary**: none of this prevents a second instance in a second process or a second classloader.