Why Did the Singleton Design Pattern Emerge and Why Is It No Longer Highly Favored?

In the software world, certain structures are designed to be created only once. For example:

1. Using a single log file throughout an application,

2. Using a single database connection,

3. Ensuring that objects such as settings or configurations have only one instance.

Singleton Design Pattern is a software design pattern created out of necessity. It ensures that a class has only one instance and provides a global point of access to that instance.

Eager Singleton

The earliest Singleton implementations were very simple. The object is created when the application starts. When the object is needed later, the already created instance is returned.

What Is the Problem?

Even if this object is never used, it occupies memory as soon as the application starts. For large resource-intensive objects, this can be a significant waste.

Lazy Singleton (Lazy but Smart)

To solve this problem, the approach “Create only when needed” was developed:

What Is the Problem With This?

This structure can cause errors in a multithreaded environment. If two different threads call the getInstance() method simultaneously, two separate instances may be created because both threads can check that the instance is null and proceed to create one before the other has finished. This breaks the Singleton principle.

Mutex (Synchronized Singleton)

This issue can be resolved using a synchronization mechanism like a mutex.

But This Is Also Problematic…

Yes, it is thread-safe, but it locks on every call. This affects performance. Once a single instance has been created, there is no need to lock again, yet here locking occurs every time.

Double-Checked Locking Pattern

To avoid performance loss, the double-checked locking pattern was introduced:

This structure ensures that:

• The instance is created only when needed,
• An unnecessary lock is avoided by the first check,
• Thread safety is guaranteed by the second check.

Even this approach did not produce the desired result when first introduced, due to the structure of programming languages at the time. The issue stemmed from older language implementations. To achieve the intended behavior, the volatile keyword was introduced. The detailed reasons for this are beyond the scope of this article.

So Why Is Singleton Now Considered an Anti-Pattern?

Once widely favored, the Singleton is now regarded as an anti-pattern in most scenarios. Here are the reasons:

1. It introduces global state, making testing difficult.

2. It hides dependencies, contradicting dependency injection principles.

3. It becomes hard to control its impact elsewhere in the code (e.g., a setting silently changed).

4. Genuine cases requiring a truly single instance are very rare.

5. It causes complications in parallel programming.

6. It adds unnecessary complexity.

In Summary

The Singleton was born to solve a small problem but over time began causing larger ones. In modern software development:

• If a single instance is truly required, dependency injection with scope is preferred.
• Stateless services are favored over Singletons.