How Many Ways Can You Write a Singleton?

There are four implementations worth knowing, and they differ in when the instance is created and how thread safety is achieved.

Eager creates the instance in a static final field at class initialisation time. It is the simplest and it is thread safe, because the JVM guarantees class initialisation happens exactly once. The cost is that the instance exists even if nobody ever asks for it, so if the constructor is expensive or has side effects you pay for it whether you need it or not.

Lazy holder declares the instance inside a private static nested class and returns it from the outer class. The nested class is initialised the first time it is touched, so the instance is created on first use — and it is thread safe, because the JVM guarantees the nested class is initialised exactly once. This is the idiom most Java libraries use.

Enum declares the singleton as an enum constant. It is thread safe, it is serialisable in a way that cannot be broken by deserialisation, and it cannot be subclassed. It is the most robust of the four, and the one to reach for if you want a singleton without ceremony.

Double-checked locking uses a volatile field and a synchronised block around the creation. It is the hardest to get right, and the version people used to write before the memory model was fixed had a subtle bug where a partially constructed object could be observed. If you remember one thing about it, it is that the field must be volatile.

Here is the same thing as runnable code:

public class Main {
    public static void main(String[] args) {
        System.out.println("eager  : " + EagerConfig.INSTANCE.getName());
        System.out.println("holder : " + HolderConfig.getInstance().getName());
        System.out.println("enum   : " + EnumConfig.INSTANCE.getName());
        System.out.println("same eager instance  : " + (EagerConfig.INSTANCE == EagerConfig.INSTANCE));
        System.out.println("same enum instance   : " + (EnumConfig.INSTANCE == EnumConfig.INSTANCE));
    }
}

class EagerConfig {
    static final EagerConfig INSTANCE = new EagerConfig();

    private final String name = "eagerly created";

    private EagerConfig() {
    }

    String getName() {
        return name;
    }
}

class HolderConfig {
    // Created when the holder class is first touched.
    private static class Holder {
        static final HolderConfig INSTANCE = new HolderConfig();
    }

    private final String name = "created on first use";

    private HolderConfig() {
    }

    static HolderConfig getInstance() {
        return Holder.INSTANCE;
    }

    String getName() {
        return name;
    }
}

enum EnumConfig {
    INSTANCE;

    private final String name = "an enum singleton";

    String getName() {
        return name;
    }
}

There are two correct answers, and the difference between them is instructive.

The holder idiom avoids the whole problem. You put the instance in a private static nested class and return it from a static accessor. The JVM guarantees that a class is initialised exactly once, and that initialisation is thread safe, so the instance is created lazily and correctly with no synchronisation in your code at all. This is why it is the idiom the standard library uses.

The double-checked locking pattern does the work by hand. You check the field, and only if it is null do you take a lock, check again, and create the instance. The second check is what stops two threads creating two instances. And the field must be declared volatile — without it, the write that publishes the instance inside the lock can be reordered ahead of the assignment to the reference, so another thread can see a non-null reference to a partially constructed object.

public class Main {
    public static void main(String[] args) {
        // Many threads race to create the instance; exactly one wins.
        Thread[] threads = new Thread[20];
        for (int i = 0; i < threads.length; i++) {
            threads[i] = new Thread(() -> {
                Config c = Config.getInstance();
                if (c != Config.getInstance()) {
                    throw new IllegalStateException("two instances!");
                }
            });
            threads[i].start();
        }
        for (Thread t : threads) {
            try {
                t.join();
            } catch (InterruptedException e) {
                Thread.currentThread().interrupt();
            }
        }
        System.out.println("instance id : " + Config.getInstance().id());
    }
}

class Config {
    private static volatile Config instance;
    private final int id = 42;

    private Config() {
    }

    int id() {
        return id;
    }

    static Config getInstance() {
        Config local = instance;          // read once into a local
        if (local == null) {
            synchronized (Config.class) {
                local = instance;
                if (local == null) {
                    local = new Config();
                    instance = local;
                }
            }
        }
        return local;
    }
}

The output shows the instance id, and the twenty racing threads all agreed on the same object — the check inside the thread would have thrown if two instances had been created.

The extra local variable is not decoration. Reading the volatile field once into a local and using that local throughout means the second read inside the lock is only a safety net, and the fast path avoids the volatile read on every call.

Which to use in an interview. The holder idiom if you want lazy creation with no synchronisation code, the enum if you want robustness against reflection and deserialisation. The double-checked locking pattern is the one to explain, because it demonstrates that you understand why the volatile matters, but you would rarely write it in new code.