Singleton and Its Alternatives

Singleton is the pattern everyone learns first and the one most likely to be argued about in a code review. The disagreement is usually productive once both sides notice they are talking about different things: the requirement "exactly one instance" is often legitimate, and the mechanism "globally reachable static accessor" almost never is.

Singleton bundles the two together. Separating them is the whole topic.

The two claims inside one pattern

Claim one is a lifecycle requirement. One connection pool, one metrics registry, one configuration object. Creating a second would be wasteful or wrong.

Claim two is an access mechanism. Any code, anywhere, can reach it by naming the class. Nothing in a constructor or a signature reveals the dependency.

Almost every problem attributed to Singleton comes from claim two.

What claim two costs

class OrderService {
  submit(order) {
    Database.getInstance().save(order);       // dependency 1, invisible
    Metrics.getInstance().increment('orders'); // dependency 2, invisible
    Clock.getInstance().now();                 // dependency 3, invisible
  }
}

The dependencies are invisible. new OrderService() takes nothing, so a reader believes it needs nothing. Three collaborators are hidden inside method bodies, and the only way to find them is to read every line.

Tests share state. Whatever the singleton holds persists between tests in the same process. They pass alone and fail together, and the failures are order-dependent — the most expensive kind to diagnose.

Substitution is difficult by design. Testing the failure path needs a database that throws. With injection you pass one. With a singleton you need a static setter, which is itself global mutable state, and one test forgetting to reset it corrupts the rest of the suite.

Concurrency gets a shared mutable rendezvous point. Any mutable field on a singleton is touched by every thread, and nothing in the call sites suggests that.

Getting one instance without global reach

Create it once, at the composition root, and pass it down:

// main.js — the composition root, run once
const db = new Database(config.databaseUrl);
const metrics = new MetricsRegistry();
const clock = new SystemClock();

const orderService = new OrderService(db, metrics, clock);

class OrderService {
  constructor(db, metrics, clock) { /* … */ }   // the complete dependency list
}

This is a singleton in effect and dependency injection in structure. Exactly one Database exists, because exactly one was created. No static accessor exists, so:

• The dependencies are declared where a reader and a compiler can both see them.
• A test constructs new OrderService(fakeDb, noopMetrics, fixedClock) with no global setup and no teardown.
• Nothing can reach the database from an arbitrary corner of the codebase, so the set of code that touches it is knowable.

The uniqueness was never the problem. Discipline at one place in the code gives you uniqueness for free.

The cases where a module-level instance is fine

Pragmatism matters more than purity, and some singletons cost nothing:

Stateless helpers. A pure formatter or validator with no mutable fields. Sharing it has no observable consequences — though a plain function is usually simpler still.

Truly process-wide facilities with no test dependence. A logger is the common example, and even then, code that asserts on log output wants injection.

Language-level module caching. In most module systems, a module's top-level state is already a per-process singleton. Exporting a constructed instance is idiomatic and carries the same caveats — it is fine until something needs to substitute it.

The distinguishing question is: does it hold mutable state, and does any test need to control it? Two noes make it harmless. One yes makes it the thing people complain about.

The double-checked locking distraction

Textbook treatments spend most of their space on making lazy initialisation thread-safe — the double-checked locking idiom, and the reasons the naive version is broken without the right memory-visibility guarantees.

It is worth knowing that the naive version is genuinely broken: without a happens-before relationship, one thread can observe a non-null reference to an object whose fields are not yet visible. But it is worth noticing that the problem only exists because the instance is created lazily on first use from arbitrary threads. Construct it eagerly at start-up, on one thread, before any worker exists, and the entire category of problem is gone. Lazy initialisation is an optimisation; pay for it only when start-up cost is measured and real.

Check your understanding

Common mistakes

Treating "we need one instance" as an argument for a static accessor. It is an argument for constructing one instance.

Hiding collaborators inside method bodies. The constructor stops being the dependency list, and nothing can be substituted without global mutation.

Adding a static setter for tests. That is global mutable state introduced to work around global mutable state, and one missing reset poisons the suite.

Putting mutable state on a singleton without thinking about threads. Every thread shares it, and no call site hints at that.

Lazily initialising by default. It creates a thread-safety problem to solve a start-up cost that was never measured.

Making things singletons because there is currently one. One tenant, one region, one currency — until there is a second, and the assumption is now spread across the codebase rather than confined to one construction site.

Practice

Key takeaways

• Singleton bundles a lifecycle claim (exactly one) with an access mechanism (globally reachable). The second causes the damage.
• Global reach hides dependencies from constructors, makes substitution require static mutation, and leaks state between tests.
• Create one instance at the composition root and inject it — a singleton in effect, dependency injection in structure.
• Order-dependent test failures are the signature symptom of shared mutable state, most often a singleton.
• A module-level instance is fine when it is stateless and nothing needs to substitute it; one mutable field or one test that must control it changes the answer.
• Construct eagerly at start-up. Lazy initialisation invents a thread-safety problem to save an unmeasured cost.
• Migrate legacy accessors by inverting ownership first, then forbidding new calls, then converting class by class.

Further reading

• Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides, Design Patterns: Elements of Reusable Object-Oriented Software (Addison-Wesley, 1994).
• Mark Seemann and Steven van Deursen, Dependency Injection Principles, Practices, and Patterns (Manning, 2019).
• Brian Goetz and others, Java Concurrency in Practice (Addison-Wesley, 2006) — safe publication and lazy initialisation.
• Michael Feathers, Working Effectively with Legacy Code (Prentice Hall, 2004) — breaking static dependencies.
• Steve Freeman and Nat Pryce, Growing Object-Oriented Software, Guided by Tests (Addison-Wesley, 2009).
• Miško Hevery, "Singletons are Pathological Liars" (Google Testing Blog, 2008).