singletons and double-checked locking

the picture

you want one instance of something expensive, created only when first needed, safe under threads. the obvious version puts synchronized on get(), and then every call pays for the lock forever, even though the lock only matters once. double-checked locking (DCL) tries to skip it: check without the lock, and only lock if it's still null.

think of a shop sign. the owner hangs "open" on the door, then finishes stocking the shelves. a customer walks by, sees the sign, comes in to empty shelves. the sign (the reference) went up before the work (the constructor) was visible. the fix isn't more checks of the sign, it's a rule that the sign goes up last, and that anyone who sees the sign also sees the shelves.

here's why the sign can go up early. instance = new Config() looks like one step. it's four bytecodes:

$ javap -c S       # if (instance == null) instance = new S();   inside synchronized
  17: new           #8     // class S              allocate, all fields zero
  20: dup
  21: invokespecial #13    // Method "<init>":()V  run the constructor
  24: putstatic     #7     // Field instance:LS;    publish the reference

the bytecode order is right. but the java memory model only promises that order to the thread doing it. another thread that reads instance without synchronization has no happens-before edge with the writer, so the JIT may reorder the stores, and on a weakly ordered CPU (arm, like the mac this site was measured on) the hardware may make them visible out of order too.

the broken version, step by step

notice that thread B never touches the lock. that's the entire point of DCL, and the entire problem: the lock's happens-before guarantee only applies to threads that take it. check 2 (inside the lock) is fine. check 1 (outside) is an unsynchronized read of a field someone else is writing, which the JMM calls a data race.

we caught it

"theoretically broken" is easy to wave away. so we stress-tested the core of the bug on jdk 25 (temurin 25.0.4, apple M4 Pro, arm64): one thread keeps publishing fresh objects through a plain static field, another keeps reading it and checks for a zero field.

public class Race {
    static final class Box {
        int a, b, c, d;
        Box(int v) { a = v; b = v; c = v; d = v; }
    }
    static Box shared;              // plain: no happens-before between the threads
    static volatile boolean stop;
 
    public static void main(String[] args) throws Exception {
        Thread writer = new Thread(() -> {
            int v = 1;
            while (!stop) { shared = new Box(v); if (++v == 0) v = 1; }
        });
        long[] seen = new long[2];
        Thread reader = new Thread(() -> {
            long reads = 0, torn = 0;
            while (!stop) {
                Box h = shared;
                if (h != null) {
                    reads++;
                    if (h.a == 0 || h.b == 0 || h.c == 0 || h.d == 0) torn++;
                }
            }
            seen[0] = reads; seen[1] = torn;
        });
        writer.start(); reader.start();
        Thread.sleep(Long.parseLong(args[0]) * 1000);
        stop = true;
        writer.join(); reader.join();
        System.out.println("reads=" + seen[0] + " saw a zero field=" + seen[1]);
    }
}

$ java Race 5
reads=1583936490 saw a zero field=4
$ java Race 10
reads=3095930321 saw a zero field=8

three readings of that table: the bug is real on modern hardware, it's rare, and both standard fixes held up.

fix 1: volatile

declaring instance as volatile makes the write a release and every read an acquire. a thread whose read sees the reference is guaranteed to see everything the writer did before writing it, including the whole constructor. this works since java 5, when JSR-133 rewrote the memory model and gave volatile those ordering guarantees (before that, volatile DCL was broken too).

class Config {
    private static volatile Config instance;
 
    static Config get() {
        Config r = instance;              // one volatile read on the fast path
        if (r == null) {
            synchronized (Config.class) {
                r = instance;
                if (r == null) instance = r = new Config();
            }
        }
        return r;
    }
}

the local r is a small optimization worth knowing: it reads the volatile field once on the common path instead of twice (check, then return).

fix 2: the holder class

the JVM already has a lazy, thread-safe, run-exactly-once mechanism: class initialization. a class is initialized the first time it's actually used, and the JVM's initialization procedure takes a lock so that exactly one thread runs the static initializer while any others wait and then see its result. so hide the instance in a nested class that nothing touches until get():

static class Registry {
    static { System.out.println("Registry class initialized"); }
    private Registry() { System.out.println("Registry instance created"); }
    static String version() { return "1.0"; }
    static Registry get() { return Holder.INSTANCE; }
    private static class Holder { static final Registry INSTANCE = new Registry(); }
}
// main: System.out.println(Registry.version());

public class Main {
    static class Registry {
        static { System.out.println("Registry class initialized"); }
        private Registry() { System.out.println("Registry instance created"); }
        static String version() { return "1.0"; }
        static Registry get() { return Holder.INSTANCE; }
 
        private static class Holder {
            static final Registry INSTANCE = new Registry();
        }
    }
 
    public static void main(String[] args) {
        System.out.println("main starts");
        System.out.println(Registry.version());
        System.out.println("first get()");
        Registry a = Registry.get();
        System.out.println("second get()");
        Registry b = Registry.get();
        System.out.println(a == b);
    }
}

main starts
Registry class initialized
1.0
first get()
Registry instance created
second get()
true

no volatile, no synchronized in your code, and after the first call get() is a plain static field read that the JIT can treat as a constant. honestly, the holder only beats a plain static final INSTANCE on the outer class when that class has other static members people use without wanting the instance. otherwise the outer class is already lazy enough.

fix 3: the enum

static class Lonely {
    static final Lonely INSTANCE = new Lonely();
    private Lonely() {}
}
// reflection walks right past "private":
var k = Lonely.class.getDeclaredConstructor();
k.setAccessible(true);
k.newInstance();   // a second Lonely

enum Clock {
    INSTANCE;
    long now() { return System.nanoTime(); }
}
// the JDK refuses outright:
// IllegalArgumentException:
//   Cannot reflectively create enum objects

public class Main {
    enum Clock { INSTANCE }
 
    static class Lonely {
        static final Lonely INSTANCE = new Lonely();
        private Lonely() {}
    }
 
    public static void main(String[] args) throws Exception {
        var k = Lonely.class.getDeclaredConstructor();
        k.setAccessible(true);
        System.out.println("a second Lonely: " + (k.newInstance() != Lonely.INSTANCE));
 
        var c = Clock.class.getDeclaredConstructors()[0];
        c.setAccessible(true);
        System.out.println("a second Clock?");
        c.newInstance("INSTANCE", 0);
    }
}

a second Lonely: true
a second Clock?
Exception in thread "main" java.lang.IllegalArgumentException: Cannot reflectively create enum objects

an enum constant is created during the enum's class initialization (so it's thread-safe like the holder), reflection can't make another one, and serialization writes it by name and resolves it back to the same constant (a regular singleton needs a readResolve method for that). the catch: it's eager, and it can't extend a class.

which one