Singleton pattern

The Problem It Solves

You need exactly one database connection pool for your entire application. Multiple pools would waste memory, exhaust database connections, and create inconsistent state. The naive solution looks simple but breaks under concurrency.

If two threads call getInstance() at the same moment, both see null, both create a pool, and one silently overwrites the other. You now have two pools, leaked connections, and a mystery production bug. This is the race condition every singleton discussion starts with.

The pattern seems trivial until you consider thread safety, serialization, reflection, and testability. Those four concerns separate a working singleton from a broken one.

Here is what changes when you apply the Singleton pattern.

Structure

The private constructor prevents anyone from calling new. The Holder inner class leverages the JVM's class-loading guarantee: a class is initialized exactly once, and initialization is thread-safe without explicit synchronization. The pool is created only when getInstance() is first called (lazy) and only once (thread-safe).

Implementation

I will show three correct approaches in order of my preference. Each solves different concerns.

// APPROACH 1: Initialization-on-demand holder idiom.
// Lazy, thread-safe, no synchronized keyword, no volatile.
// The JVM spec (§12.4.2) guarantees class initialization
// is atomic and happens-before any thread reads static fields.
public class DatabaseConnectionPool {
  private final String jdbcUrl;
  private final int poolSize;

  // Private constructor: nobody outside can instantiate
  private DatabaseConnectionPool() {
      this.jdbcUrl = System.getenv("DB_URL");
      this.poolSize = Integer.parseInt(
          System.getenv().getOrDefault("POOL_SIZE", "10"));
      System.out.println("Pool created with " + poolSize + " connections");
  }

  // Inner class is NOT loaded until getInstance() is called.
  // When it IS loaded, JVM guarantees single-threaded init.
  private static final class Holder {
      static final DatabaseConnectionPool INSTANCE =
          new DatabaseConnectionPool();
  }

  public static DatabaseConnectionPool getInstance() {
      return Holder.INSTANCE;
  }

  public String getJdbcUrl() { return jdbcUrl; }
  public int getPoolSize() { return poolSize; }
}

The Testability Problem

The biggest criticism of singleton is not thread safety (that is solved). It is testability. Singleton creates hidden global state that makes unit tests depend on each other.

// Problem: tests that use ConfigService.getInstance() share state.
// Test A modifies the singleton, Test B runs next and unexpectedly
// sees Test A's changes. Test order matters. Parallel tests break.

// Solution: Dependency Injection. Pass the instance, don't fetch it.
public class OrderService {
    private final ConfigService config; // injected, not fetched

    // Constructor injection: tests control which instance is used
    public OrderService(ConfigService config) {
        this.config = config;
    }

    public int getMaxRetries() {
        return Integer.parseInt(config.get("max.retries"));
    }
}
// In production: new OrderService(ConfigService.getInstance())
// In tests:      new OrderService(mockConfigService)

In an interview, this is the key insight: "I know how to implement singleton correctly, but in production I would use dependency injection so the singleton is wired at the composition root. Classes receive their dependencies, they don't fetch globals."

How It Works

The sequence diagram shows the holder idiom under concurrent access. The JVM handles thread safety, so no application-level synchronization is needed.

1. Thread A calls getInstance(), which references Holder.INSTANCE for the first time.
2. The JVM loads the Holder class. The JVM specification guarantees this happens atomically. No application synchronization needed.
3. During class loading, INSTANCE is initialized. The DatabaseConnectionPool constructor runs exactly once.
4. Thread B calls getInstance() concurrently. If class loading is in progress, Thread B blocks on the JVM's internal lock. If done, Thread B reads the fully-constructed instance.
5. Both threads get the same instance. The happens-before relationship of class initialization guarantees all fields are visible.

Real-World Examples

• java.lang.Runtime.getRuntime() returns the singleton Runtime instance. There is exactly one runtime per JVM process, managing memory and external processes.
• Spring's default bean scope is singleton. When you annotate a class with @Service, Spring creates one instance and injects it everywhere. This is singleton via DI container, not via getInstance().
• SLF4J's LoggerFactory maintains a singleton logging framework binding. One binding per application, selected at startup, used by every class that calls LoggerFactory.getLogger().
• java.awt.Desktop.getDesktop() returns a singleton representing the user's desktop environment. Only one desktop exists per user session.

When to Use / When NOT to Use

Use when:

• The resource is inherently singular (connection pool, thread pool, hardware interface)
• Creating multiple instances would cause resource exhaustion or state conflicts
• You need a global coordination point (registry, cache, configuration)

Skip when:

• You want testability (use DI to inject the instance instead of calling getInstance())
• The class has mutable state that tests modify (tests will interfere with each other)
• You are using it as a glorified global variable to avoid passing parameters

If the resource is truly singular (one pool, one config), singleton makes sense as a lifecycle mechanism. But let the DI container manage it, not getInstance() calls scattered through your codebase.

Common Mistakes in Interviews

1. Writing the broken version and calling it done. The naive if (instance == null) check is not thread-safe. If an interviewer asks for singleton, they expect you to explain the race condition and fix it. Start with the broken version on purpose, then upgrade.

2. Using synchronized on the entire method. This makes every call pay the synchronization cost, even after the instance exists. Double-checked locking avoids this. Say: "Synchronizing the whole method works but is slower. Double-checked locking synchronizes only the first creation."

3. Forgetting volatile in double-checked locking. Without volatile, the JVM can reorder the write to instance before the constructor finishes. Thread B sees a non-null reference but a partially-constructed object. This is the most commonly missed detail.

4. Not mentioning testability. Candidates who only describe implementation miss the bigger picture. Always say: "The real problem with singleton is testability. In production, I inject the instance via constructor instead of calling getInstance() directly."

5. Dismissing enum singleton as weird. Enum singleton is Josh Bloch's explicit recommendation in Effective Java. It handles serialization and reflection with zero boilerplate. Say: "Enum singleton covers edge cases that the holder idiom does not, specifically serialization and reflection attacks."

Singleton vs Static Class vs Dependency Injection

The key takeaway: static classes are for stateless utilities. Singletons are for stateful resources that must be unique. DI-managed singletons are the production-preferred approach where the framework handles lifecycle and testability.

Test Your Understanding

Quick Recap

1. The naive if (instance == null) singleton has a race condition. Two threads can create two instances if they interleave at the null-check.
2. The Holder idiom (inner static class) is lazy, thread-safe, and needs no synchronized or volatile. It relies on the JVM's class-loading guarantee.
3. Double-checked locking needs volatile to prevent partial construction visibility. Without it, another thread can see a non-null but incomplete object.
4. Enum singleton is serialization-safe and reflection-safe. It is Josh Bloch's recommendation in Effective Java.
5. The real problem with singleton is testability, not thread safety. Global state makes unit tests depend on each other and prevents mocking.
6. In production, use dependency injection to manage singleton lifecycle. The DI container creates one instance and injects it everywhere.
7. In an interview, show the broken version first, explain the race condition, then present the fix. Mention testability and DI to differentiate yourself.