Explore Topics
🎯
Intent
Ensure exactly one instance — and offer a global way to reach it.
🧪 Singleton Variant Lab — 4 variants × 4 scenarios
🚀 App Startup: JVM boots, classes get loaded. No client has touched the singleton yet.
Eager Initialization
instances: 1
When created: Built at class load
thread-safe: ✓ yesexception-safe: ✗ no
Already constructed before main() runs.
Static Block Init
instances: 1
When created: Built in static block at class load
thread-safe: ✓ yesexception-safe: ✓ yes
Constructor runs inside try/catch — checked exceptions become RuntimeException.
Lazy Initialization
instances: 0
When created: Not yet built
thread-safe: —exception-safe: —
Singleton class loaded but the `instance` field is still null.
Bill Pugh Holder
instances: 0
When created: Holder class NOT loaded yet
thread-safe: ✓ yesexception-safe: —
Outer class is loaded, but the nested Holder is deferred — true laziness.
| Property | Eager | Static Block | Lazy | Bill Pugh |
|---|---|---|---|---|
| Lazy? | ✗ | ✗ | ✓ | ✓ |
| Thread-safe? | ✓ (JVM) | ✓ (JVM) | ✗ | ✓ (JVM) |
| Exception handling? | ✗ | ✓ try/catch | caller sees | ✓ in Holder |
| Performance | fastest | fastest | fastest (no sync) | fastest |
| Verdict | always-need | always + throws | teaching only | modern default ★ |
Pick a scenario above to see how each variant behaves. Toggle Matrix ↔ Timeline for the two perspectives.
🎯
Intent
Ensure exactly one instance — and offer a global way to reach it.
Singleton is a creational design pattern that guarantees a class has only one instance and provides a single global access point to that instance. It also encapsulates "just-in-time initialization" — the instance comes into existence on first use, not by anyone calling `new` from outside. The pattern actually solves two problems at once (uniqueness + access), which is exactly why it is sometimes criticized as an SRP violation: a class is taking on both its business responsibility and the responsibility of policing its own creation.
Key Ideas
- Hide the constructor (private) so nobody outside the class can call `new`.
- Hold the unique instance in a private static field.
- Expose a public static `getInstance()` that returns that one instance.
- Solves uniqueness AND access in one pattern — which is also the SRP complaint.
- Variants differ only in WHEN and HOW the instance is created.
Strengths
- ✦Guaranteed single instance across the whole JVM
- ✦Globally reachable without parameter-passing
- ✦Lazy variants delay heavy initialization
- ✦Centralizes control of a shared resource
Weaknesses
- △Smuggles global state into the design
- △Hides dependencies — callers don't see what they rely on
- △Hard to unit-test (cannot mock the call to a static method)
- △Mixes uniqueness concern with business logic (SRP debate)
Used in:Configuration manager, logger, thread pool, connection pool, and ID/account-number generators all need exactly one shared instance per process.
Code Snippets
Quiz
Intent Quiz
QUIZ 1/6Which statement best captures the GoF Intent of the Singleton pattern?
Diagrams
Practice
Drag each property to the Singleton variant it BEST describes. Each variant accepts exactly two properties.
EXERCISE 1/4Built at class load — wastes init cost if unused
Simplest reference, no synchronization needed
Wraps construction in try/catch for checked exceptions
Eager + exception handling, still not lazy
NOT thread-safe under concurrent first-time access
Textbook idiom for teaching lazy initialization
Uses a nested static Holder class
Lazy AND thread-safe by JVM guarantee — no synchronized
Eager Initialization
Static Block Initialization
Lazy Initialization
Bill Pugh (Holder Idiom)
Spot the bug — why is this NOT a real Singleton?
EXERCISE 2/4Click on the line you think contains the bug, then press Confirm.
Complete the Bill Pugh holder-idiom singleton
EXERCISE 3/4public class Config {
// Block external construction:
Config() { /* load config */ }
// The lazy, thread-safe holder:
private class Holder {
private static final Config INSTANCE = new Config();
}
public static Config getInstance() {
return .INSTANCE;
}
}
Singleton myths and gotchas — true or false?
EXERCISE 4/4A class with all static fields and static methods is the same as a Singleton.
The textbook lazy initialization (if instance == null then new ...) is thread-safe out of the box.
Bill Pugh's holder idiom requires no `synchronized` keyword to be thread-safe.
The Singleton pattern is just a fancy name for a global variable.
In Java, marking a Singleton as `Serializable` is enough to preserve its singleton-ness across serialization.
Eager Singleton wastes nothing — the instance is only "built" once anyway.
A Bill Pugh Singleton's Holder class is loaded when the outer class is loaded.