Thread-safe Singleton implementations?

• Eager – private static final INSTANCE = new X(): created at class load, thread-safe for free.
• Synchronized getInstance – lazy and correct, but every call acquires the lock.
• Double-checked locking – volatile field, null check outside lock, re-check inside; fast after creation.
• Bill Pugh holder – private static inner class not loaded until first use; lazy, lock-free.
• Enum singleton – single instance guaranteed by JVM; serialization-safe, reflection-safe.

What is eager initialization?

The simplest approach creates the instance as a static final field. The JVM guarantees that class initialization is thread-safe, so no synchronization is needed.

package com.bank.pool;

public class ConnectionPool {
    private static final ConnectionPool INSTANCE = new ConnectionPool();
    private ConnectionPool() {}
    public static ConnectionPool getInstance() { return INSTANCE; }
}

Thread-safe because the JVM's class loading mechanism ensures only one thread initializes a class. Downside: the instance is created even if never used, which matters if construction is expensive.

What is synchronized getInstance?

package com.bank.pool;

public class ConnectionPool {
    private static ConnectionPool instance;
    private ConnectionPool() {}
    public static synchronized ConnectionPool getInstance() {
        if (instance == null) instance = new ConnectionPool();
        return instance;
    }
}

Lazy and correct, but every call acquires the lock. Under high concurrency at National Bank of India, this becomes a bottleneck because threads serialize at the synchronized method even though the instance was created long ago.

What is double-checked locking?

Double-checked locking avoids the lock on every call by checking null outside the synchronized block first.

package com.bank.pool;

public class ConnectionPool {
    private static volatile ConnectionPool instance;  // MUST be volatile
    private ConnectionPool() {}
    public static ConnectionPool getInstance() {
        if (instance == null) {                       // first check (no lock)
            synchronized (ConnectionPool.class) {
                if (instance == null) {               // second check (locked)
                    instance = new ConnectionPool();
                }
            }
        }
        return instance;
    }
}

The volatile keyword is mandatory. Without it, another thread could see a non-null reference to an object whose constructor has not finished executing. This is because instance = new ConnectionPool() is not atomic: it involves (1) allocating memory, (2) calling the constructor, and (3) assigning the reference. The JVM may reorder steps 2 and 3, so another thread sees a non-null reference to an uninitialized object.

What is the Bill Pugh holder idiom?

package com.bank.pool;

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

The inner class Holder is not loaded until getInstance() references it, so initialization is lazy. The JVM's class-init lock makes it thread-safe. No volatile, no synchronized, and no performance penalty after initialization.

What is the enum singleton?

package com.bank.pool;

public enum ConnectionPool {
    INSTANCE;

    private final java.util.List<java.sql.Connection> connections = new java.util.ArrayList<>();

    public java.sql.Connection getConnection() {
        // pool logic
        return null;
    }
}

Simplest and most robust. The JVM guarantees a single instance. It is immune to serialization attacks (deserialization returns the same instance) and reflection attacks (the JVM prevents reflective construction of enum instances).

How do they compare?

| Approach | Lazy | Thread-safe | Serialization-safe | Reflection-safe | Performance |
|----------|------|-------------|-------------------|-----------------|-------------|
| Eager | No | Yes | Needs readResolve | No | Best |
| Synchronized | Yes | Yes | Needs readResolve | No | Worst |
| Double-checked | Yes | Yes (if volatile) | Needs readResolve | No | Good |
| Bill Pugh | Yes | Yes | Needs readResolve | No | Best |
| Enum | No | Yes | Yes | Yes | Best |

How can reflection break a non-enum Singleton?

// Reflection attack on a non-enum Singleton
Constructor<ConnectionPool> ctor = ConnectionPool.class.getDeclaredConstructor();
ctor.setAccessible(true);
ConnectionPool second = ctor.newInstance();  // creates a second instance!
// second != ConnectionPool.getInstance()  -- Singleton broken!

// Defense: throw in the private constructor
private ConnectionPool() {
    if (INSTANCE != null) throw new IllegalStateException("Singleton already created");
}

Enum singletons are immune because the JVM throws IllegalArgumentException when you try to reflectively construct an enum.

What is readResolve for serialization safety?

When a Singleton is serialized and deserialized, Java creates a new object. The readResolve method tells the serialization framework to replace the deserialized object with the existing Singleton.

private Object readResolve() {
    return INSTANCE;  // discard the deserialized object
}

What are common interview follow-up questions?

• Is the Singleton pattern still relevant with dependency injection? Yes, DI containers manage the lifecycle (typically singleton scope), but understanding the pattern matters for non-DI contexts and interviews.
• Why was double-checked locking broken before Java 5? Before Java 5, the JMM did not guarantee that volatile would prevent the reordering issue. The new JMM in Java 5 fixed this.
• How do you test a Singleton? Inject the instance or use an interface so tests can provide a mock implementation.