Singletons in Java

1. Introduction

In this quick tutorial, we’ll discuss the two most popular ways of implementing Singletons in plain Java.

2. Class-Based Singleton

The most popular approach is to implement a Singleton by creating a regular class and making sure it has:

• a private constructor
• a static field containing its only instance
• a static factory method for obtaining the instance

We’ll also add an info property for later use only. So our implementation will look like this:

public final class ClassSingleton {

    private static ClassSingleton INSTANCE;
    private String info = "Initial info class";
    
    private ClassSingleton() {        
    }
    
    public static ClassSingleton getInstance() {
        if(INSTANCE == null) {
            INSTANCE = new ClassSingleton();
        }
        
        return INSTANCE;
    }

    // getters and setters
}

While this is a common approach, it’s important to note that it can be problematic in multithreading scenarios, which is the main reason for using Singletons.

Simply put, it can result in more than one instance, breaking the pattern’s core principle. Although there are locking solutions to this problem, our next approach solves these problems at a root level.

3. Enum Singleton

Moving forward, let’s discuss another interesting approach, which is to use enumerations:

public enum EnumSingleton {
    
    INSTANCE("Initial class info"); 
 
    private String info;
 
    private EnumSingleton(String info) {
        this.info = info;
    }
 
    public EnumSingleton getInstance() {
        return INSTANCE;
    }
    
    // getters and setters
}

This approach has serialization and thread-safety guaranteed by the enum implementation itself, which ensures internally that only the single instance is available. This corrects the problems pointed out in the class-based implementation.

4. Usage

To use our ClassSingleton, we simply need to get the instance statically:

ClassSingleton classSingleton1 = ClassSingleton.getInstance();

System.out.println(classSingleton1.getInfo()); //Initial class info

ClassSingleton classSingleton2 = ClassSingleton.getInstance();
classSingleton2.setInfo("New class info");

System.out.println(classSingleton1.getInfo()); //New class info
System.out.println(classSingleton2.getInfo()); //New class info

As for the EnumSingleton, we can use it like any other Java Enum:

EnumSingleton enumSingleton1 = EnumSingleton.INSTANCE.getInstance();

System.out.println(enumSingleton1.getInfo()); //Initial enum info

EnumSingleton enumSingleton2 = EnumSingleton.INSTANCE.getInstance();
enumSingleton2.setInfo("New enum info");

System.out.println(enumSingleton1.getInfo()); // New enum info
System.out.println(enumSingleton2.getInfo()); // New enum info

5. Common Pitfalls

Singleton is a deceptively simple design pattern, and there are a few common mistakes that a programmer might commit when creating a singleton.

We can distinguish two types of issues with singletons:

• existential (do we need a singleton?)
• implementational (did we implement it properly?)

5.1. Existential Issues

Conceptually, a singleton is a kind of global variable. In general, we know that global variables should be avoided, especially if their states are mutable.

We’re not saying that we should never use singletons; however, we are saying that there might be more efficient ways to organize our code.

If a method’s implementation depends on a singleton object, why not pass it as a parameter? In this case, we explicitly show what the method depends on. As a result, we may easily mock these dependencies (if necessary) when performing testing.

For example, singletons are often used to encompass the application’s configuration data (i.e., connection to the repository). If they’re used as global objects, it becomes difficult to choose the configuration for the test environment.

Therefore, when we run the tests, the production database gets spoiled with the test data, which is hardly acceptable.

If we need a singleton, we might consider the possibility of delegating its instantiation to another class, a sort of factory, that should take care of assuring that there’s just one instance of the singleton in play.

5.2. Implementational Issues

Even though the singletons seem quite simple, their implementations may suffer from various issues. All result in the fact that we might end up having more than just one instance of the class.

Synchronization
The implementation with a private constructor that we presented above isn’t thread-safe. It works well in a single-threaded environment, but in a multi-threaded one, we should use the synchronization technique to guarantee the atomicity of the operation:

public synchronized static ClassSingleton getInstance() {
    if (INSTANCE == null) {
        INSTANCE = new ClassSingleton();
    }
    return INSTANCE;
}

Note the keyword synchronized in the method declaration. The method’s body has several operations (comparison, instantiation, and return).

In the absence of synchronization, there’s a possibility that two threads interleave their executions in such a way that the expression INSTANCE == null evaluates to true for both threads, and as a result, two instances of ClassSingleton get created.

Synchronization might significantly affect the performance. If this code gets invoked often, we should speed it up using various techniques like lazy initialization or double-checked locking (be aware that this might not work as expected due to compiler optimizations).  We can see more details in our article “Double-Checked Locking with Singleton.”

Multiple Instances
There are several other issues with the singletons related to the JVM itself that could cause us to end up with multiple instances of a singleton. These issues are quite subtle, and we’ll give a brief description for each of them:

1. A singleton is supposed to be unique per JVM. This might be a problem for distributed systems or systems whose internals are based on distributed technologies.
2. Every class loader might load its version of the singleton.
3. A singleton might be garbage-collected once no one holds a reference to it. This issue doesn’t lead to the presence of multiple singleton instances at a time, but when recreated, the instance might differ from its previous version.

6. Conclusion

In this brief article, we focused on how to implement the Singleton pattern using only core Java. We learned how to make sure it’s consistent, and how to make use of these implementations.