Thread-Safe Singleton Patterns in Java — Enum, Holder, DCL, Eager

Four canonical thread-safe singleton patterns in Java, each with distinct trade-offs.

1. Enum singleton — the default

public enum ConfigService { INSTANCE; ... }

• Thread-safe: JVM class-init lock
• Serialization-safe: enum identity preserved automatically
• Reflection-safe: Constructor.newInstance refuses enums
• Zero boilerplate
• Recommended by Joshua Bloch's Effective Java Item 3
• Downside: no subclassing, harder to refactor out of singleton

2. Initialization-on-demand holder idiom — class-based lazy

private static class Holder {
  static final Singleton INSTANCE = new Singleton();
}
public static Singleton getInstance() { return Holder.INSTANCE; }

• Holder class loaded only on first getInstance() — lazy
• JVM class-init is thread-safe, no volatile, no synchronized
• Performs identically to DCL
• Use when: class semantics preferred, no constructor args needed

3. Double-checked locking with volatile — for parameterized singletons

private static volatile Singleton instance;
Singleton local = instance;
if (local == null) { synchronized(...) { ... } }

• Only when construction needs runtime arguments
• volatile is mandatory — without it, still broken on Java 21
• More code than enum or holder
• Use sparingly

4. Eager static initialization — simplest

public static final Singleton INSTANCE = new Singleton();

• Created at class load
• Not lazy; wastes memory if never used
• Use when: construction is cheap and it's always used

The two attacks on class-based singletons

Serialization:

• Default mechanism creates a new instance on deserialize
• Fix: implement readResolve() returning the existing singleton
• Enum immune automatically

Reflection:

• Constructor.getDeclaredConstructor().setAccessible(true).newInstance() can bypass private constructors
• Fix: throw from the constructor if instance already exists
• Only enum is truly reflection-proof

Decision flow

• Spring/Jakarta EE? → @Component with default scope; don't hand-roll
• Need constructor args? → DCL with volatile
• Cheap and always used? → Eager static
• Otherwise → enum
• Want class semantics but also lazy? → Holder idiom

Testing implications

• Singletons pin global state; tests can contaminate each other
• Prefer DI: @Component with Spring context per test, or plain constructor injection
• Avoid static getInstance() accessors in testable business code

Multi-classloader caveat

• In OSGi, app servers, plugin systems: one instance per classloader, not global
• Both class-based and enum are affected
• Rarely matters in typical Spring Boot apps

Recommendation: For application code running in Spring or Jakarta EE, stop hand-rolling singletons — let the container manage scope. For framework or library code that truly needs a global instance, default to enum; it's the only pattern that's simultaneously simple, lazy, serialization-safe, and reflection-safe. Reach for the holder idiom when you specifically want a class instead of an enum (e.g., extending a parent class or implementing complex behavior). Use DCL with volatile only when you need constructor arguments; usually that signals you actually want a small cache, not a singleton. And never write a plain synchronized getInstance() — it's obsolete. Finally, treat any mutable singleton as a risk: the singleton identity is preserved but the mutable state inside it still needs its own thread-safety story.