Singleton Design Pattern

---

Dark Mode

Show Highlights

Audio Clips

Context

In software engineering, certain classes represent concepts that should only exist once during the entire execution of a program. Common examples include thread pools, caches, dialog boxes, logging objects, and device drivers. In these scenarios, having more than one instance is not just unnecessary but often harmful to the system’s integrity. In a UML class diagram, this requirement is explicitly modeled by specifying a multiplicity of “1” in the upper right corner of the class box, indicating the class is intended to be a singleton.

Problem

The primary problem arises when instantiating more than one of these unique objects leads to incorrect program behavior, resource overuse, or inconsistent results. For instance, accidentally creating two distinct “Earth” objects in a planetary simulation would break the logic of the system.

While developers might be tempted to use global variables to manage these unique objects, this approach introduces several critical flaws:

• High Coupling: Global variables allow any part of the system to access and potentially mess around with the object, creating a web of dependencies that makes the code hard to maintain.
• Lack of Control: Global variables do not prevent a developer from accidentally calling the constructor multiple times to create a second, distinct instance.
• Instantiation Issues: You may want the flexibility to choose between “eager instantiation” (creating the object at program start) or “lazy instantiation” (creating it only when first requested), which simple global variables do not inherently support.

Solution

The Singleton Pattern solves these issues by ensuring a class has only one instance while providing a controlled, global point of access to it. The solution consists of three main implementation aspects:

1. A Private Constructor: By declaring the constructor private, the pattern prevents external classes from ever using the new keyword to create an instance.
2. A Static Field: The class maintains a private static variable (often named uniqueInstance) to hold its own single instance.
3. A Static Access Method: A public static method, typically named getInstance(), serves as the sole gateway to the object.

UML Role Diagram

UML Example Diagram

Sequence Diagram

Refining the Solution: Thread Safety and Performance

The “Classic Singleton” implementation uses lazy instantiation, checking if the instance is null before creating it. However, this is not thread-safe; if two threads call getInstance() simultaneously, they might both find the instance to be null and create two separate objects.

There are several ways to handle this in Java:

• Synchronized Method: Adding the synchronized keyword to getInstance() makes the operation atomic but introduces significant performance overhead, as every call to get the instance is forced to wait in a queue, even after the object has already been created.
• Eager Instantiation: Creating the instance immediately when the class is loaded avoids thread issues entirely but wastes memory if the object is never actually used during execution.
• Double-Checked Locking: This advanced approach uses the volatile keyword on the instance field to ensure it is handled correctly across threads. It checks for a null instance twice—once before entering a synchronized block and once after—minimizing the performance hit of synchronization to only the very first time the object is created.

Consequences

Applying the Singleton Pattern results in several important architectural outcomes:

• Controlled Access: The pattern provides a single point of access that can be easily managed and updated.
• Resource Efficiency: It prevents the system from being cluttered with redundant, resource-intensive objects.
• The Risk of “Singleitis”: A major drawback is the tendency for developers to overuse the pattern. Using a Singleton just for easy global access can lead to a hard-to-maintain design with high coupling, where it becomes unclear which classes depend on the Singleton and why.
• Complexity in Testing: Singletons can be difficult to mock during unit testing because they maintain state throughout the lifespan of the application. A static getInstance() call is a hardcoded dependency—there is no seam where a test double can be injected. This is why the pattern is considered an anti-pattern in test-driven development.

A Pattern with a “Weak Solution”

The Singleton is perhaps the most controversial of all GoF patterns. Buschmann et al. (POSA5) describe it as “a well-known pattern with a weak solution”, noting that “the literature that discusses [Singleton’s] issues dwarfs the page count of the original pattern description in the Gang-of-Four book.” The core problem is that the pattern conflates two separate concerns:

1. Ensuring a single instance—a legitimate design constraint.
2. Providing global access—a convenience that introduces hidden coupling.

Modern practice separates these concerns. A dependency injection (DI) container can manage the singleton lifetime (ensuring only one instance exists) while keeping constructors injectable and dependencies explicit. This gives you the same lifecycle guarantee without the testability and coupling problems.

When Singleton is Acceptable

The Singleton pattern remains acceptable when:

• It controls a true infrastructure resource (e.g., a hardware driver in an embedded system).
• DI is genuinely unavailable (small scripts, legacy code).
• Testability of consuming code is not a concern.

In all other cases, prefer DI with singleton scope. As Feathers puts it: “If your code isn’t testable, it isn’t a good design.”

When Singleton is an Anti-Pattern

• When the “only one” assumption is actually a convenience assumption, not a hard requirement. Many “singletons” later need multiple instances (per-tenant, per-thread, per-test).
• When it is used to create global state—making it impossible to reason about what depends on what.
• When it blocks unit testing by making dependencies invisible and unmockable.

Flashcards

Singleton Pattern Flashcards

Key concepts, controversies, and modern alternatives for the Singleton design pattern.

What are the three implementation aspects of Singleton?

(1) Private constructor, (2) private static field holding the instance, (3) public static getInstance() method as sole access point.

The private constructor prevents external instantiation. The static field stores the single instance. The static method provides controlled access.

Why is Singleton controversial in modern practice?

It conflates two concerns: ensuring a single instance (legitimate) and providing global access (harmful coupling). DI containers solve the first without introducing the second.

POSA5 calls it ‘a well-known pattern with a weak solution.’ The literature discussing Singleton’s issues dwarfs the original GoF description.

Name three thread-safety approaches for Singleton in Java.

(1) Synchronized getInstance() (simple, slow), (2) Eager instantiation in static field (fast, may waste memory), (3) Double-checked locking with volatile (efficient, complex).

The classic lazy singleton is not thread-safe. Each approach trades off simplicity, performance, and memory. Java’s enum approach is considered the safest.

What is ‘Singleitis’?

The tendency to overuse Singleton for easy global access, creating high coupling and unclear dependencies — a form of the ‘Hammer and Nail’ syndrome.

Using Singleton just for convenience rather than a genuine ‘exactly one instance’ constraint leads to a hard-to-maintain design where dependencies are invisible.

When is Singleton acceptable in modern code?

When controlling a true infrastructure resource where DI is unavailable and testability of consuming code is not a concern. In all other cases, prefer DI with singleton scope.

A DI container can manage singleton lifetime (ensuring one instance) while keeping constructors injectable and dependencies explicit, avoiding the testability problem.

Workout Complete!

Your Score: 0/5

Come back later to improve your recall!

Quiz

Singleton Pattern Quiz

Test your understanding of the Singleton pattern's controversies, thread-safety mechanisms, and modern alternatives.

POSA5 describes the Singleton as “a well-known pattern with a weak solution.” What is the core reason for this criticism?

Correct Answer:

Explanation

Singleton conflates legitimate lifetime management with a harmful global access point, introducing hidden coupling and making testing impossible. The criticism targets the solution, not the problem. Ensuring a single instance is a legitimate need. But using a static getInstance() method as a global access point (1) creates hidden dependencies, (2) makes mocking impossible in tests, and (3) tightly couples all consumers to a specific context. DI containers solve the lifetime problem without introducing global access.

Two threads simultaneously call getInstance() on a classic lazy Singleton. Both find uniqueInstance == null and both create a new instance. Which thread-safety approach eliminates this race condition with the simplest implementation and zero per-call overhead — at the cost of not being lazy?

Correct Answer:

Explanation

Eager instantiation eliminates the race condition at zero per-call overhead by creating the instance at class-load time, at the cost of not being lazy. Eager instantiation creates the instance when the class is loaded (in a static field initializer), eliminating the race condition entirely with zero per-call overhead — subsequent calls just return the already-created static field. The trade-off is that the instance is created even if it is never used. Synchronized getInstance() works but forces every call through synchronization. Double-checked locking preserves laziness with minimal overhead (a volatile read per call), but is significantly more complex to implement correctly.

A system uses Singleton for a database connection pool. A new requirement: the system must support multi-tenant deployments with one pool per tenant. What is the fundamental problem?

Correct Answer:

Explanation

Multi-tenant support invalidates the Singleton’s core ‘exactly one’ assumption, revealing it was a convenience rather than a genuine hard constraint. This reveals the fragility of Singleton: the ‘exactly one’ assumption was actually a convenience, not a hard requirement. Many ‘singletons’ later need per-tenant, per-thread, or per-test instances. DI with singleton scope per tenant avoids this problem entirely — the container manages one pool per tenant without hardcoding the cardinality into the code.

A developer argues: “Our Logger class uses the Singleton pattern, and it’s fine — we never need to test it.” What is wrong with this reasoning?

Correct Answer:

Explanation

The problem is not testing the Logger itself, but testing everything that depends on it — a hidden getInstance() call cannot be replaced with a test double. The testability problem with Singleton is not about testing the Singleton itself — it’s about testing everything that depends on it. Any class that calls Logger.getInstance() has a hidden, hardcoded dependency that cannot be replaced with a test double. This makes it impossible to verify that a class logs correctly, or to suppress logging noise during tests. The dependency is invisible in the constructor signature.

Which of the following are legitimate reasons to use the Singleton pattern? (Select all that apply)

Correct Answers:

Explanation

Singleton is legitimate only for true infrastructure resources where DI is unavailable — convenience and avoiding constructor injection are not valid reasons. Options A and C describe legitimate uses: true infrastructure resources where DI is genuinely unavailable. Options B and D describe convenience, not necessity — and convenience-driven Singletons create hidden coupling and harm testability. ‘Making it convenient to access globally’ is exactly the problem POSA5 criticizes. Constructor injection makes dependencies explicit, which is a feature, not a burden.

Workout Complete!

Your Score: 0/5