Thread-safe Singleton

1 · Naive lazy — the broken baseline

Here is the version everyone writes first. It has no protection of any kind:

public static Printer getInstance() {
    if (instance == null) {          // ① T1 reads null ... and so does T2
        instance = new Printer();    // ② both build. TWO instances exist.
    }
    return instance;                 // ③ each thread returns a different object
}

Run the prototype in ❌ Naive mode and you can watch it happen: T1 reads the field and sees null, then T2 reads it before T1 has written anything and also sees null. Both enter the branch, both call new Printer(), and 🏭 instances created ticks to 2. Each thread walks away holding a different object with a different queue — which is precisely the bug a Singleton exists to prevent. Worse, it's intermittent: on most runs the timing works out fine, so this bug ships to production and shows up once a week under load.

2 · synchronized — correct, but you pay forever

The obvious fix is a lock: put synchronized on the method so only one thread can be inside it at a time. A lock is a key to a room — you can't enter until whoever has the key comes out. Now T1 takes the key, checks, builds, and leaves; T2 waits, gets the key, checks, sees the instance already exists, and returns it. One instance, guaranteed.

The cost is that the lock is on every call, forever. In the prototype's 🐢 synchronized mode, run all three rounds: 🔒 lock acquisitions climbs to 6 even though the instance was built on the very first one. Rounds 2 and 3 acquire and release a lock purely to read a field that will never change again — and T2 still blocks in amber, waiting its turn. On a hot path called from many threads, that queue at the door becomes real contention.

3 · Double-checked locking — lock only when it might matter

Double-checked locking (DCL) removes the everyday cost by checking twice: once cheaply without the lock, and once again inside it. Think of a window in the supply-room door — you look through the window first (free), and only if the corner looks empty do you bother taking the key, and then you look again inside the room before ordering anything.

private static volatile Printer instance;      // volatile is NOT optional

public static Printer getInstance() {
    if (instance == null) {                    // ① fast path, no lock
        synchronized (Printer.class) {         // ② only the first callers get here
            if (instance == null) {            // ③ check AGAIN, now under the lock
                instance = new Printer();
            }
        }
    }
    return instance;                           // later calls never touch the lock
}

The second check is the one that does the work. Two threads can both fail check ①, but only one of them gets the lock; by the time the loser is let in, check ③ is false and it just returns what's already there. After that first call, every future call fails check ① immediately and returns without touching the lock at all. In the prototype's ⚡ DCL + volatile mode, the lock counter moves during round 1 and then stops rising — that's the whole payoff.

4 · The static holder idiom — lazy AND lock-free

Here's the punchline: you can get lazy initialisation with no lock and no null check at all, by making the language do it. Every JVM already guarantees that a class is initialised exactly once, and that all threads see the finished result — it takes an internal lock during class loading and then never again. So put the instance in a tiny private nested class that isn't loaded until someone actually touches it. This is the Bill Pugh or initialization-on-demand holder idiom:

public class Printer {
    private Printer() {}

    private static class Holder {                  // not loaded until first touched
        static final Printer INSTANCE = new Printer();   // JVM: runs exactly once
    }

    public static Printer getInstance() {
        return Holder.INSTANCE;                    // no lock, no null check
    }
}

Holder isn't loaded when Printer is loaded — only when Holder.INSTANCE is first read. That read triggers class initialisation, the JVM builds the instance once under its own one-time lock, and every call afterwards is a plain field read. You get lazy (nothing is built until first use), thread-safe (guaranteed by the class loader), and fast (zero synchronisation in your code) — and the method body is one line. In the prototype's 🏅 Holder mode the lane is visibly the shortest of the four and 🔒 lock acquisitions stays at 0.

Eager initialisation — the honest simple option

You can also just write private static final Printer INSTANCE = new Printer(); directly on the class. The JVM's one-time class-initialisation guarantee makes this completely thread-safe with zero ceremony. The only thing you lose is laziness: the object is built the moment the class loads, whether or not anyone ever asks for it. That's fine for something cheap, and wasteful for something that opens sockets or reads files. The scoreboard row 🥱 Eager field in the prototype shows exactly that trade: 1 instance, 0 locks, lazy: ✗. The holder idiom exists to give you the same safety without giving up laziness.

Other languages have their own guarantees

• Python — a plain module-level object is already a singleton, because a module's body executes exactly once on first import and the import machinery holds a lock while it does. If you must build one lazily inside a class, wrap the check-and-create in a threading.Lock — the GIL does not make check-then-act safe.
• C++11 and later — a static local variable inside a function (a Meyers singleton) is guaranteed by the standard to be initialised exactly once, with other threads blocked until it's done. These are nicknamed magic statics. std::call_once with a std::once_flag is the explicit equivalent.
• Go — sync.Once is the idiom: once.Do(func() { instance = newPrinter() }) runs the function exactly once no matter how many goroutines call it, and guarantees the result is visible to all of them. Package-level var plus func init() is the eager equivalent.
• C# — Lazy<T> with the default thread-safety mode does the whole job for you, and a static readonly field gets the same one-time initialisation guarantee from the CLR.

Pick the implementation like this

• Default: the static holder idiom (or enum in Java, a module-level object in Python, a function-local static in C++, sync.Once in Go). Lazy, thread-safe, lock-free, and short enough to get right on the first try.
• Eager static final field — when the object is cheap to build and certain to be used. Simplest possible correct code; you're only paying startup cost you were going to pay anyway.
• Double-checked locking — when you genuinely need lazy creation and the holder idiom doesn't fit, typically because the instance depends on runtime arguments or lives in a non-static field. Write volatile. Never skip it.
• Plain synchronized method — fine when getInstance() is called rarely, or in a quick prototype. Correct is better than clever; optimise only if the lock actually shows up in a profile.

Step back before you optimise the lock

The best fix is often to not need a lazy global at all. Create the one instance at startup and pass it to whatever needs it — dependency injection gives you "exactly one" without any of this, and it stays testable. See Dependency Injection & IoC. If you do keep a singleton, remember that thread-safe creation is only half the job: the object's own mutable state still needs its own locking or immutability, as covered by Singleton's trade-offs.