Java Singleton: 5% Requests Routed Wrong (Missing Volatile)

Every non-trivial Java application has resources that are expensive to create, dangerous to duplicate, or logically absurd to have more than one of — a connection pool, an application-wide config loader, a logging service. If every class that needs the logger creates its own instance, you waste memory, fragment your log output, and risk race conditions. This is the exact problem the Singleton pattern was designed to solve, and it's why you'll find it baked into frameworks like Spring, Hibernate, and the Java standard library itself.

Why the Naive Singleton Breaks Under Multithreading

The most obvious Singleton implementation — a private constructor plus a static getInstance() method — works perfectly in single-threaded code. But the moment two threads call getInstance() simultaneously before the instance is created, both can slip past the null check, and you end up with two separate instances. That defeats the entire purpose.

This is called a race condition, and it's subtle. In production it might only surface under load, making it one of those nasty bugs that's hard to reproduce locally. The code below shows the broken version first so you can see exactly what goes wrong — then we fix it.

The broken version has no synchronization on the critical section where the instance is first created. Thread A reads instance == null as true, gets paused by the scheduler, Thread B also reads instance == null as true and creates the object, then Thread A resumes and creates a SECOND object. Two singletons. Chaos.

// ❌ BROKEN: This singleton is NOT thread-safe.
// Two threads can both pass the null check before either sets the field.

public class BrokenSingleton {

    // The one instance — starts as null until first requested
    private static BrokenSingleton instance;

    // Private constructor prevents anyone outside this class calling `new BrokenSingleton()`
    private BrokenSingleton() {
        System.out.println("BrokenSingleton created by thread: " + Thread.currentThread().getName());
    }

    // ❌ No synchronization — race condition lives here
    public static BrokenSingleton getInstance() {
        if (instance == null) {               // Thread A and Thread B can BOTH pass this check
            instance = new BrokenSingleton(); // ...and BOTH create an instance
        }
        return instance;
    }

    public static void main(String[] args) throws InterruptedException {
        // Spin up 5 threads all trying to grab the instance at the same time
        for (int i = 0; i < 5; i++) {
            Thread thread = new Thread(() -> {
                BrokenSingleton singleton = BrokenSingleton.getInstance();
                System.out.println("Got instance with hashCode: " + singleton.hashCode());
            });
            thread.start();
        }
    }
}

Double-Checked Locking: The Production-Ready Singleton

The gold-standard fix is called Double-Checked Locking (DCL). The idea: only synchronize during the brief window when the instance is first being created. Once it exists, reads are unsynchronized and fast.

The trick that makes it work is the volatile keyword on the instance field. Without volatile, the JVM's memory model allows instruction reordering — the JVM could write a half-constructed object to instance before its constructor finishes, and another thread could see a non-null but broken object. volatile forces a full memory barrier, preventing that reordering.

DCL is the approach you'll see in professional codebases. It's performant because synchronization only happens once (during creation), and it's correct because volatile closes the memory-visibility gap. It's also worth knowing the Bill Pugh / Initialization-on-Demand Holder idiom as an elegant alternative — shown at the end of this section.

// ✅ CORRECT: Double-Checked Locking Singleton — thread-safe and performant
// Real-world use case: Application-wide configuration manager

public class ThreadSafeSingleton {

    // `volatile` is NON-NEGOTIABLE here — it prevents the JVM from publishing
    // a half-constructed object to other threads due to instruction reordering
    private static volatile ThreadSafeSingleton instance;

    private final String configFilePath;
    private final int maxConnections;

    // Private constructor loads config once — expensive operation done only once
    private ThreadSafeSingleton() {
        System.out.println("[CONFIG] Loading configuration... (thread: "
                + Thread.currentThread().getName() + ")");
        this.configFilePath = "/etc/myapp/config.yaml"; // simulate reading from disk
        this.maxConnections = 50;
    }

    public static ThreadSafeSingleton getInstance() {
        // FIRST check (no lock): if instance already exists, return immediately — fast path
        if (instance == null) {

            // Only one thread can enter this block at a time
            synchronized (ThreadSafeSingleton.class) {

                // SECOND check (inside lock): another thread may have created
                // the instance while we were waiting to acquire the lock
                if (instance == null) {
                    instance = new ThreadSafeSingleton();
                }
            }
        }
        return instance; // returns the same object every single time after creation
    }

    public String getConfigFilePath() { return configFilePath; }
    public int getMaxConnections()    { return maxConnections; }

    public static void main(String[] args) throws InterruptedException {
        Runnable task = () -> {
            ThreadSafeSingleton config = ThreadSafeSingleton.getInstance();
            System.out.println(Thread.currentThread().getName()
                    + " -> hashCode: " + config.hashCode()
                    + ", maxConnections: " + config.getMaxConnections());
        };

        // Launch 6 threads simultaneously — only ONE constructor call should happen
        Thread[] threads = new Thread[6];
        for (int i = 0; i < 6; i++) {
            threads[i] = new Thread(task, "Worker-" + i);
        }
        for (Thread t : threads) t.start();
        for (Thread t : threads) t.join(); // wait for all threads to finish
    }
}

Enum Singleton: The Bulletproof Version You Should Know

Here's a trick that catches a lot of developers off guard: Java's enum type is itself a Singleton. The JVM guarantees that each enum constant is instantiated exactly once, is thread-safe by default, and — crucially — is protected against two attacks that break every other Singleton implementation: serialization and reflection.

With a normal Singleton, a malicious or careless developer can call Constructor.setAccessible(true) via reflection and invoke the private constructor, creating a second instance. Similarly, deserializing a serialized Singleton creates a fresh object. Both of these bypass your getInstance() logic entirely.

The enum approach blocks both attacks. The JVM outright refuses to instantiate enum types via reflection, and the serialization mechanism for enums returns the existing constant rather than a new instance. Joshua Bloch — the author of Effective Java — explicitly recommends this approach. Use it when you're building a Singleton that might be serialized or when security matters.

// ✅ BULLETPROOF: Enum Singleton — reflection-safe, serialization-safe, thread-safe
// Real-world use case: Application event bus or centralized audit logger

public enum EnumSingleton {

    // This is the single instance — the JVM creates it exactly once, guaranteed
    INSTANCE;

    private int eventCount = 0;
    private final String logPrefix = "[AUDIT]";

    // Your actual business methods go here — treat INSTANCE like a regular object
    public void logEvent(String eventDescription) {
        eventCount++;
        System.out.println(logPrefix + " Event #" + eventCount
                + " | " + eventDescription
                + " | Logged by: " + Thread.currentThread().getName());
    }

    public int getTotalEventCount() {
        return eventCount;
    }

    public static void main(String[] args) throws Exception {
        // Normal usage — call via INSTANCE
        EnumSingleton.INSTANCE.logEvent("User login: alice@example.com");
        EnumSingleton.INSTANCE.logEvent("File uploaded: report_q3.pdf");

        // Try to break it with reflection — the JVM will throw an exception
        try {
            java.lang.reflect.Constructor<EnumSingleton> constructor =
                    EnumSingleton.class.getDeclaredConstructor(String.class, int.class);
            constructor.setAccessible(true);
            EnumSingleton hackedInstance = constructor.newInstance("FAKE", 0); // ❌ This will fail
        } catch (Exception e) {
            // JVM protects enum — reflection attack is blocked
            System.out.println("Reflection attack blocked: " + e.getClass().getSimpleName());
        }

        System.out.println("Total events logged: " + EnumSingleton.INSTANCE.getTotalEventCount());
        System.out.println("Instance hashCode: " + EnumSingleton.INSTANCE.hashCode());
    }
}

Real-World Singletons in Java — Where You're Already Using Them

The Singleton pattern isn't just an academic exercise — you use it constantly without realizing it. Understanding where it already appears in Java helps you recognize when to reach for it in your own code.

Runtime.getRuntime() returns the single JVM Runtime instance. System.out is a static final field — one PrintStream, used everywhere. Spring's ApplicationContext is effectively a Singleton container — every bean marked @Scope("singleton") (the default) is managed as a Singleton by the framework. Hibernate's SessionFactory is designed to be instantiated once per application because creating it is extremely expensive.

The pattern to recognize is this: if creating multiple instances of something would either waste significant resources or produce logically incorrect behavior (imagine two separate config stores with different values), that thing is a Singleton candidate.

When NOT to use it: Singletons make unit testing harder because they carry state across tests. They're also a form of global state, which creates hidden coupling between classes. Use dependency injection to pass the single instance around rather than having classes call getInstance() directly — that way you can swap in a mock during testing.

// Demonstrating real Singletons already in the Java standard library

public class RealWorldSingletonDemo {

    public static void main(String[] args) {

        // --- 1. Runtime Singleton ---
        // Runtime.getRuntime() always returns the same Runtime object
        Runtime jvmRuntime = Runtime.getRuntime();
        System.out.println("Available processors: " + jvmRuntime.availableProcessors());
        System.out.println("Max JVM memory (bytes): " + jvmRuntime.maxMemory());

        // Calling it again returns the SAME instance — same hashCode
        Runtime anotherReference = Runtime.getRuntime();
        System.out.println("Same Runtime instance? " + (jvmRuntime == anotherReference)); // true

        // --- 2. Bill Pugh Holder Idiom (elegant lazy singleton, no synchronization needed) ---
        // The inner class is only loaded when getInstance() is first called
        DatabaseConnectionPool pool1 = DatabaseConnectionPool.getInstance();
        DatabaseConnectionPool pool2 = DatabaseConnectionPool.getInstance();
        System.out.println("Same pool instance? " + (pool1 == pool2)); // true
        pool1.executeQuery("SELECT * FROM users WHERE active = true");
    }
}

// Bill Pugh Initialization-on-Demand Holder — clean, lazy, thread-safe without volatile or synchronized
class DatabaseConnectionPool {

    private final int poolSize;

    private DatabaseConnectionPool() {
        this.poolSize = 10;
        System.out.println("[DB POOL] Connection pool initialized with " + poolSize + " connections.");
    }

    // The JVM only loads this inner class when getInstance() is first called
    // Class loading in Java is thread-safe — no extra synchronization needed
    private static final class PoolHolder {
        private static final DatabaseConnectionPool POOL_INSTANCE = new DatabaseConnectionPool();
    }

    public static DatabaseConnectionPool getInstance() {
        return PoolHolder.POOL_INSTANCE; // inner class loaded here on first call
    }

    public void executeQuery(String sql) {
        System.out.println("[DB POOL] Executing on pool (size=" + poolSize + "): " + sql);
    }
}

The Bill Pugh Holder Idiom: Lazy Initialization Without Synchronization

The Bill Pugh Initialization-on-Demand Holder idiom is the cleanest way to achieve lazy initialization with full thread safety — no volatile, no synchronized, no double-checked locking. It exploits a guarantee of the JVM: class loading is inherently thread-safe. When getInstance() is called for the first time, the JVM loads the inner Holder class and initializes the static field. That initialization is serialized by the JVM's class-loading mechanism, so no two threads can create the instance.

This pattern is ideal when you need lazy loading (e.g., the singleton initializes a heavy resource) and you don't need reflection or serialization protection. It's simple, readable, and performant — the best choice for most production scenarios where an enum's eager initialization is not acceptable.

// ✅ Bill Pugh Holder Idiom — lazy, thread-safe, no volatile or synchronized
// Real-world use case: Lazy-loaded event bus or heavy configuration loader

public class BillPughSingleton {

    // The Holder class is loaded only when getInstance() is called
    private static final class SingletonHolder {
        private static final BillPughSingleton INSTANCE = new BillPughSingleton();
    }

    private final String eventBusName;

    private BillPughSingleton() {
        this.eventBusName = "MainEventBus";
        System.out.println("[EVENT BUS] Initializing " + eventBusName);
    }

    public static BillPughSingleton getInstance() {
        return SingletonHolder.INSTANCE; // class loaded here on first call
    }

    public void publishEvent(String event) {
        System.out.println("[EVENT BUS] Publishing: " + event);
    }

    public static void main(String[] args) throws InterruptedException {
        Runnable task = () -> {
            BillPughSingleton bus = BillPughSingleton.getInstance();
            bus.publishEvent("User logged in");
            System.out.println("Bus hashCode: " + bus.hashCode());
        };

        Thread[] threads = new Thread[5];
        for (int i = 0; i < 5; i++) {
            threads[i] = new Thread(task, "Worker-" + i);
        }
        for (Thread t : threads) t.start();
        for (Thread t : threads) t.join();
    }
}

UML Class Diagram of Singleton Pattern

The essence of the Singleton pattern is captured in a simple UML class diagram. There is exactly one class, with a private static field of its own type, a private constructor, and a public static method that returns the instance. The diagram below shows the classic structure.

The pattern's elegance lies in its minimalism: no interfaces, no inheritance, just a single class that polices its own instantiation. The private constructor ensures no external class can call new, and the static factory method (getInstance()) controls creation and access.

When to Use the Singleton Pattern (Applicability)

The Singleton pattern isn't a hammer for every nail. Use it only when all three of these criteria are met:

1. Shared Resource: There is a resource that must be shared across the entire application. Examples: a database connection pool, a configuration cache, a thread pool, or a logging service. Having multiple instances would either exhaust resources (too many connections) or cause inconsistent state (different threads see different config values).
2. Global Access Point: The resource needs to be accessible from many different parts of the codebase without passing it through every constructor. This is a practical concession — in theory, passing dependencies via constructors is cleaner. But for genuinely cross-cutting concerns like logging or metrics, a global access point reduces boilerplate.
3. Control Instantiation Count: You need strict enforcement that only one instance ever exists. If your design allows multiple instances but just happens to use one, you don't need a Singleton — you need a configurable pool or a factory. Singleton is mandatory when duplication would cause corruption or security issues.

If your use case doesn't satisfy all three, consider alternatives: static methods for utility classes, instance pooling for databases, or dependency injection with scoped beans.

Singleton Implementation Comparison: Synchronized Method, DCL, Bill Pugh, Enum

Choosing the right Singleton implementation depends on your thread-safety, lazy-initialization, and security requirements. The table below summarizes the four most common thread-safe approaches.

• Synchronized Method: Simplest but has synchronization overhead on every call. Suitable for low-concurrency scenarios.
• Double-Checked Locking: Fast path after initialization, but requires volatile. Most common in production Java code.
• Bill Pugh Holder: Cleanest lazy init, no synchronization keywords. Recommended for most applications that don't need serialization/reflection protection.
• Enum Singleton: The only option that blocks reflection and serialization attacks automatically. Optimal for security-sensitive or serialized singletons, but eager initialization may increase startup time.

Pros and Cons of the Singleton Pattern

The Singleton pattern is a double-edged sword. Here's a balanced look at its advantages and disadvantages.

Pros: - Guarantees a single instance: Prevents duplicate resource allocation and logical inconsistencies. - Saves memory and resources: Heavy objects (config, connection pools) are created once and shared. - Provides a global access point: getInstance() is simple and familiar to all developers. - Lazy initialization: Instance is created only when first requested, improving startup time. - Can be thread-safe: Multiple implementations exist for concurrent environments.

Cons: - Global state: Singletons introduce hidden dependencies and can lead to tight coupling. - Unit testing is harder: State persists across tests; mocking requires extra effort. - Violates the Single Responsibility Principle: The class both manages its lifecycle and performs its business logic. - Concurrency bugs: If not implemented correctly, leads to race conditions and corruption. - Reflection and serialization attacks: Default implementations are vulnerable unless using Enum. - Can mask design problems: Developers may overuse Singletons instead of passing dependencies properly.

Relations with Other Design Patterns

The Singleton pattern frequently collaborates with other creational and structural patterns. Here are three key relationships.

Facade Pattern: A Facade class often acts as a single entry point to a complex subsystem. It is commonly implemented as a Singleton to ensure all clients use the same simplified interface. For example, a TransactionFacade that sits in front of multiple microservices might be a Singleton so that all callers share the same cached context.

Flyweight Pattern: Flyweight uses sharing to support large numbers of fine-grained objects efficiently. The Flyweight factory that manages the pool of shared objects is a natural Singleton — you don't want multiple factories creating duplicate Flyweight objects. In graphics rendering, a FontCache Singleton ensures each font is loaded only once.

Abstract Factory Pattern: Abstract Factory provides an interface for creating families of related objects. The concrete factory itself is often a Singleton, because you want exactly one way to produce a consistent family of products. For instance, a GUIFactory for a specific operating system should be instantiated once per application launch.

Understanding these relationships helps you recognize when Singleton is used as a supporting actor rather than the star. In each case, Singleton solves the 'one and only one' requirement for the factory or cache manager.