ThreadLocal OOM? Exploring Singleton Pitfalls in Java Multithreading

1. Background Knowledge

Among the most widely used design patterns, the Singleton pattern provides a simple way to ensure that a class creates only one instance, reducing object creation overhead and easing garbage‑collection pressure.

Its advantages include saving the cost of repeated new operations for frequently used objects and lowering memory usage, which in turn reduces GC pauses.

Incorrect use of the Singleton pattern in multithreaded code can cause serious errors, so it is worth studying carefully.

2. Eager Singleton

The eager (or "hungry") singleton creates the instance at class loading time. The implementation must satisfy three requirements:

The instance field is private static to guarantee safety and accessibility.

The constructor is private to prevent external instantiation.

A public static method (e.g., Singleton.getInstance()) returns the instance.

This approach is simple and performs well under multithreading, but it creates the instance even if it is never used, which can be wasteful.

Because the static variable is initialized when the class loads, the constructor may be invoked before any explicit call to getInstance(), making it difficult to control the exact creation time.

3. Thread‑Safe Lazy Singleton

The thread‑safe lazy version delays instance creation until the first call to getInstance(). Its code is shown below:

As long as getInstance() is not invoked, the singleton instance is not created, ensuring true lazy initialization.

4. Double‑Checked Locking (DCL)

DCL attempts to combine lazy initialization with high performance by checking the instance twice—once without locking and once inside a synchronized block. The code looks complex and uses volatile to prevent reordering:

Although DCL is considered ugly and error‑prone—especially on older JDK versions—it remains an interesting study of concurrency control.

5. Static Inner Class

The static inner‑class technique leverages the class‑loader mechanism to achieve lazy, thread‑safe initialization without explicit synchronization:

Key benefits include:

Instance creation is deferred until getInstance() is called.

The JVM guarantees that the inner class is loaded only once, providing inherent thread safety.

The implementation is concise and reliable.

Understanding these singleton variations helps avoid pitfalls such as unintended instance creation, memory leaks (e.g., ThreadLocal‑related OOM), and performance degradation in Java multithreaded applications.