Singleton Pattern in Java

The Java Singleton pattern belongs to the family of design patterns that governs the instantiation process. A Singleton is an object that cannot be instantiated. This design pattern suggests that at any time there can only be one instance of a Singleton (object) created by the JVM. You implement the pattern by creating a class with a method that creates a new instance of the class if one does not exist. If an instance of the class exists, it simply returns a reference to that object.

How the Singleton pattern works

Here’s a typical example of Singleton:

public class Singleton {
private final static Singleton INSTANCE = new Singleton();

// Private constructor suppresses generation of a (public) default constructor
private Singleton() {}

public static Singleton getInstance() {
return INSTANCE;
}
}

The classic Singleton does not use direct instantiation of a static variable with declaration — it instantiates a static instance variable in the constructor without checking to see if it already exists:

public class ClassicSingleton {
private static ClassicSingleton INSTANCE = null;
private ClassicSingleton() {
// Exists only to defeat instantiation.
}
public static ClassicSingleton getInstance() {
if(INSTANCE == null) {
INSTANCE = new ClassicSingleton();
}
return INSTANCE;
}
}

The Singleton class’s default constructor is made private, which prevents the direct instantiation of the object by other classes using the new keyword. A static modifier is applied to the instance method that returns the Singleton object; it makes this a class level method that can be accessed without creating an object.
When you need Singleton

Singletons are truly useful when you need only one instance of a class, and it is undesirable to have more than one instance of a class.

When designing a system, you usually want to control how an object is used and prevent users (including yourself) from making copies of it or creating new instances. For example, you can use it to create a connection pool. It’s not wise to create a new connection every time a program needs to write something to a database; instead, a connection or a set of connections that are already a pool can be instantiated using the Singleton pattern.

The Singleton pattern is often used in conjunction with the factory method pattern to create a systemwide resource whose specific type is not known to the code that uses it. An example of using these two patterns together is the Abstract Windowing Toolkit (AWT). In GUI applications, you often need only one instance of a graphical element per application instance, like the Print dialog box or the OK button.
Watch out for potential problems

Although the Singleton design pattern is one of the simplest design patterns, it presents a number of pitfalls.

Construct in multi-threaded applications
You must carefully construct the Singleton pattern in multi-threaded applications. If two threads are to execute the creation method at the same time when a Singleton does not exist, both must check for an instance of the Singleton, but only one thread should create the new object. The classic solution to this problem is to use mutual exclusion on the class that indicates that the object is being instantiated. This is a thread-safe version of a Singleton:

public class Singleton
{
// Private constructor suppresses generation a (public) default constructor
private Singleton() {}

private static class SingletonHolder
{
private final static Singleton INSTANCE = new Singleton();
}

public static Singleton getInstance()
{
return SingletonHolder.INSTANCE;
}
}

For an alternative solution, you can add the synchronized keyword to the getInstance() method declaration:

public static synchronized Singleton getInstance()

Think ahead about cloning prevention
You can still create a copy of the Singleton object by cloning it using the Object’s clone() method. To forbid this, you need to override the Object’s clone method, which throws a CloneNotSupportedException exception:

public Object clone() throws CloneNotSupportedException {
throw new CloneNotSupportedException();
}

Consider making the singleton class final
You may want to make the Singleton class final to avoid sub classing of Singletons that may cause other problems.

Remember about garbage collection
Depending on your implementation, your Singleton class and all of its data might be garbage collected. This is why you must ensure that there must be a live reference to the Singleton class when the application is running.