Singleton Pattern — Thread-Safe Implementations (DCL vs Enum)

The challenge with Singleton in Java isn't the pattern itself — it's making it thread-safe without killing performance. Three approaches work correctly, and they differ in laziness, complexity, and resilience to serialization attacks.

Double-Checked Locking uses a volatile instance field with two null checks — one outside and one inside the synchronized block. The volatile keyword is mandatory because new Singleton() involves multiple writes internally, and without it the JVM can reorder the reference assignment before the constructor completes. Another thread sees a non-null reference pointing to a half-constructed object — fields still at default values.

The holder idiom is cleaner. A private static inner class holds the instance, and because the JVM guarantees class initialization is atomic and lazy, the first call to getInstance() triggers class loading which safely creates the instance. No volatile, no synchronized, no overhead after initialization.

The enum singleton is what Joshua Bloch recommends in Effective Java. The JVM guarantees one instance per enum constant, handles serialization automatically, and blocks reflection attacks by throwing on Constructor.newInstance(). The tradeoff is that enums can't extend a class.

In practice, most Spring applications never need any of this. @Component beans are singletons by default — the container handles lifecycle and thread safety. I only implement Singleton manually for pre-container utilities like connection pools or configuration caches that initialize before Spring starts.