The Loneliest Pattern: A Deep Dive into the Singleton

In the world of software engineering, there are times when “the more, the merrier” is exactly the wrong philosophy. Sometimes, you need exactly one—and only one—instance of a class to coordinate actions across a system. Enter the Singleton Design Pattern.

What is the Singleton Pattern?

The Singleton is a creational design pattern that ensures a class has only one instance while providing a global access point to that instance. Think of it like the “Government” of your application; there might be many departments, but there is only one central authority that everyone refers to.

Why Use It?

The primary driver for using a Singleton is resource management. Creating multiple instances of heavy objects—like database connection pools, socket connections, or logger configurations—can lead to memory leaks, inconsistent states, and performance bottlenecks.

Key Benefits:

• Controlled Access: Strict control over how and when clients access the instance.
• Reduced Memory Footprint: You aren’t clogging the heap with redundant objects.
• Global State: A consistent way to share data across different parts of the application.

Implementation in Plain Java

public final class Singleton {
    // 1. Private static variable to hold the single instance
    private static Singleton instance = null;
    // 2. Private constructor so no one else can use 'new'
    private Singleton() {
        // Initialization logic here
    }
    // 3. Static method to provide global access
    public static synchronized Singleton getInstance() {
        if (instance == null) {
            instance = new Singleton();
        }
        return instance;
    }
}

Why static? Since the constructor is private, you can’t create an object to call the method. Making the method static allows you to call Singleton.getInstance() from anywhere.

Singletons in the Wild: The Java JDK

While many think of java.util.Calendar as a singleton because of getInstance(), it actually returns a new instance based on the locale and timezone each time. However, the JDK uses true Singletons in other critical areas:

• java.lang.Runtime: Every Java application has a single instance of Runtime class that allows the application to interface with the environment. Accessed via Runtime.getRuntime().
• java.awt.Desktop: Provides a single instance to interact with the user’s desktop features.

How Modern Frameworks Use It

In the modern era, we rarely write “Manual Singletons” because frameworks do the heavy lifting for us.

Spring Framework

In Spring, the Singleton is the default scope for any defined Bean. When you annotate a class with @Service or @Component, Spring’s IoC (Inversion of Control) container creates one instance and “wires” it into every other class that needs it.

Benefit: You don’t have to manage the static logic. Spring ensures that whenever you @Autowired that service, you’re getting the exact same object.

Adobe Experience Manager (AEM)

In AEM, OSGi Services function as Singletons within the OSGi container.

• When you define a service using @Component(service = MyService.class), the OSGi framework instantiates it once.
• Components like Sling Servlets or Schedulers interact with these services as singletons, ensuring that configurations and heavy resources (like JCR sessions) are handled efficiently without redundant overhead.