Java Singleton Pattern is one of the Gangs of Four Design patterns and comes in the Creational Design Pattern category. From the definition, it seems to be a straightforward design pattern, but when it comes to implementation, it comes with a lot of concerns.
In this article, we will learn about singleton design pattern principles, explore different ways to implement the singleton design pattern, and some of the best practices for its usage.
java.lang.Runtime
, java.awt.Desktop
).To implement a singleton pattern, we have different approaches, but all of them have the following common concepts.
In further sections, we will learn different approaches to singleton pattern implementation and design concerns with the implementation.
In eager initialization, the instance of the singleton class is created at the time of class loading. The drawback to eager initialization is that the method is created even though the client application might not be using it. Here is the implementation of the static initialization singleton class:
package com.journaldev.singleton;
public class EagerInitializedSingleton {
private static final EagerInitializedSingleton instance = new EagerInitializedSingleton();
// private constructor to avoid client applications using the constructor
private EagerInitializedSingleton(){}
public static EagerInitializedSingleton getInstance() {
return instance;
}
}
If your singleton class is not using a lot of resources, this is the approach to use. But in most of the scenarios, singleton classes are created for resources such as File System, Database connections, etc. We should avoid the instantiation unless the client calls the getInstance
method. Also, this method doesn’t provide any options for exception handling.
Static block initialization implementation is similar to eager initialization, except that instance of the class is created in the static block that provides the option for exception handling.
package com.journaldev.singleton;
public class StaticBlockSingleton {
private static StaticBlockSingleton instance;
private StaticBlockSingleton(){}
// static block initialization for exception handling
static {
try {
instance = new StaticBlockSingleton();
} catch (Exception e) {
throw new RuntimeException("Exception occurred in creating singleton instance");
}
}
public static StaticBlockSingleton getInstance() {
return instance;
}
}
Both eager initialization and static block initialization create the instance even before it’s being used and that is not the best practice to use.
Lazy initialization method to implement the singleton pattern creates the instance in the global access method. Here is the sample code for creating the singleton class with this approach:
package com.journaldev.singleton;
public class LazyInitializedSingleton {
private static LazyInitializedSingleton instance;
private LazyInitializedSingleton(){}
public static LazyInitializedSingleton getInstance() {
if (instance == null) {
instance = new LazyInitializedSingleton();
}
return instance;
}
}
The preceding implementation works fine in the case of the single-threaded environment, but when it comes to multi-threaded systems, it can cause issues if multiple threads are inside the if
condition at the same time. It will destroy the singleton pattern and both threads will get different instances of the singleton class. In the next section, we will see different ways to create a thread-safe singleton class.
A simple way to create a thread-safe singleton class is to make the global access method synchronized so that only one thread can execute this method at a time. Here is a general implementation of this approach:
package com.journaldev.singleton;
public class ThreadSafeSingleton {
private static ThreadSafeSingleton instance;
private ThreadSafeSingleton(){}
public static synchronized ThreadSafeSingleton getInstance() {
if (instance == null) {
instance = new ThreadSafeSingleton();
}
return instance;
}
}
The preceding implementation works fine and provides thread-safety, but it reduces the performance because of the cost associated with the synchronized method, although we need it only for the first few threads that might create separate instances. To avoid this extra overhead every time, double-checked locking principle is used. In this approach, the synchronized block is used inside the if
condition with an additional check to ensure that only one instance of a singleton class is created. The following code snippet provides the double-checked locking implementation:
public static ThreadSafeSingleton getInstanceUsingDoubleLocking() {
if (instance == null) {
synchronized (ThreadSafeSingleton.class) {
if (instance == null) {
instance = new ThreadSafeSingleton();
}
}
}
return instance;
}
Continue your learning with Thread Safe Singleton Class.
Prior to Java 5, the Java memory model had a lot of issues, and the previous approaches used to fail in certain scenarios where too many threads tried to get the instance of the singleton class simultaneously. So Bill Pugh came up with a different approach to create the singleton class using an inner static helper class. Here is an example of the Bill Pugh Singleton implementation:
package com.journaldev.singleton;
public class BillPughSingleton {
private BillPughSingleton(){}
private static class SingletonHelper {
private static final BillPughSingleton INSTANCE = new BillPughSingleton();
}
public static BillPughSingleton getInstance() {
return SingletonHelper.INSTANCE;
}
}
Notice the private inner static class that contains the instance of the singleton class. When the singleton class is loaded, SingletonHelper
class is not loaded into memory and only when someone calls the getInstance()
method, this class gets loaded and creates the singleton class instance. This is the most widely used approach for the singleton class as it doesn’t require synchronization.
Reflection can be used to destroy all the previous singleton implementation approaches. Here is an example class:
package com.journaldev.singleton;
import java.lang.reflect.Constructor;
public class ReflectionSingletonTest {
public static void main(String[] args) {
EagerInitializedSingleton instanceOne = EagerInitializedSingleton.getInstance();
EagerInitializedSingleton instanceTwo = null;
try {
Constructor[] constructors = EagerInitializedSingleton.class.getDeclaredConstructors();
for (Constructor constructor : constructors) {
// This code will destroy the singleton pattern
constructor.setAccessible(true);
instanceTwo = (EagerInitializedSingleton) constructor.newInstance();
break;
}
} catch (Exception e) {
e.printStackTrace();
}
System.out.println(instanceOne.hashCode());
System.out.println(instanceTwo.hashCode());
}
}
When you run the preceding test class, you will notice that hashCode
of both instances is not the same which destroys the singleton pattern. Reflection is very powerful and used in a lot of frameworks like Spring and Hibernate. Continue your learning with Java Reflection Tutorial.
To overcome this situation with Reflection, Joshua Bloch suggests the use of enum
to implement the singleton design pattern as Java ensures that any enum
value is instantiated only once in a Java program. Since Java Enum values are globally accessible, so is the singleton. The drawback is that the enum
type is somewhat inflexible (for example, it does not allow lazy initialization).
package com.journaldev.singleton;
public enum EnumSingleton {
INSTANCE;
public static void doSomething() {
// do something
}
}
Sometimes in distributed systems, we need to implement Serializable
interface in the singleton class so that we can store its state in the file system and retrieve it at a later point in time. Here is a small singleton class that implements Serializable
interface also:
package com.journaldev.singleton;
import java.io.Serializable;
public class SerializedSingleton implements Serializable {
private static final long serialVersionUID = -7604766932017737115L;
private SerializedSingleton(){}
private static class SingletonHelper {
private static final SerializedSingleton instance = new SerializedSingleton();
}
public static SerializedSingleton getInstance() {
return SingletonHelper.instance;
}
}
The problem with serialized singleton class is that whenever we deserialize it, it will create a new instance of the class. Here is an example:
package com.journaldev.singleton;
import java.io.FileInputStream;
import java.io.FileNotFoundException;
import java.io.FileOutputStream;
import java.io.IOException;
import java.io.ObjectInput;
import java.io.ObjectInputStream;
import java.io.ObjectOutput;
import java.io.ObjectOutputStream;
public class SingletonSerializedTest {
public static void main(String[] args) throws FileNotFoundException, IOException, ClassNotFoundException {
SerializedSingleton instanceOne = SerializedSingleton.getInstance();
ObjectOutput out = new ObjectOutputStream(new FileOutputStream(
"filename.ser"));
out.writeObject(instanceOne);
out.close();
// deserialize from file to object
ObjectInput in = new ObjectInputStream(new FileInputStream(
"filename.ser"));
SerializedSingleton instanceTwo = (SerializedSingleton) in.readObject();
in.close();
System.out.println("instanceOne hashCode="+instanceOne.hashCode());
System.out.println("instanceTwo hashCode="+instanceTwo.hashCode());
}
}
That code produces this output:
OutputinstanceOne hashCode=2011117821
instanceTwo hashCode=109647522
So it destroys the singleton pattern. To overcome this scenario, all we need to do is provide the implementation of readResolve()
method.
protected Object readResolve() {
return getInstance();
}
After this, you will notice that hashCode
of both instances is the same in the test program.
Read about Java Serialization and Java Deserialization.
This article covered the singleton design pattern.
Continue your learning with more Java tutorials.
Thanks for learning with the DigitalOcean Community. Check out our offerings for compute, storage, networking, and managed databases.
Sign up for Infrastructure as a Newsletter.
Working on improving health and education, reducing inequality, and spurring economic growth? We'd like to help.
Get paid to write technical tutorials and select a tech-focused charity to receive a matching donation.
I mean if you added volatile to the singleton it would not get destroyed by the reflection pattern Use double-check locking principle when there is not so many thread use bill pugh singleton implementation when you have many threads private static volatile DBSingleton instance = null; private DBSingleton() { if(instance != null){ throw new RuntimeException(“Use getInstance() method to create”); } } public static DBSingleton getInstance() { if(instance == null){ synchronized (DBSingleton.class){ if (instance == null){ instance = new DBSingleton(); } } } return instance; } }
- Islam
Double checked locking strategy does not work in multi thread environment due to compiler optimization in java plese see http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html
- Vishwam
Wonderful explanation, thank you so much!
- saravan
Wrong way to implement double-lock.Instance = new ThreadSafeSingleton();It’s possible to reorder.Returns without initializing the object.
- Thomas
> Prior to Java 5, java memory model had a lot of issues and the above approaches used to fail in certain scenarios where too many threads try to get the instance of the Singleton class simultaneously. Could you give an example? How about we make the `instance` volatile? Will this avoid above issues? ``` public class ThreadSafeSingleton { private static volatile ThreadSafeSingleton instance; private ThreadSafeSingleton(){} public static ThreadSafeSingleton getInstanceUsingDoubleLocking(){ if(instance == null){ synchronized (ThreadSafeSingleton.class) { if(instance == null){ instance = new ThreadSafeSingleton(); } } } return instance; } } ```
- Jiabin
Hi Pankaj, I follow your articles. I think the below code is thread safe as the object will be created only once. package com.journaldev.singleton; public class EagerInitializedSingleton { private static final EagerInitializedSingleton instance = new EagerInitializedSingleton(); //private constructor to avoid client applications to use constructor private EagerInitializedSingleton(){} public static EagerInitializedSingleton getInstance(){ return instance; } } Please clarify? Thanks Naidu
- Naidu
Which approach is preferred? DCC with volatile instance of singleton OR static inner helper class Noticed the volatile instance case isn’t mentioned here
- Heena
I recommend capitalizing “instance” in the eager initialization example, as it follows convention, but also drives home the point of the instance being final and created at class load.
- Jeremiah
if is condition not loop :)
- Sajal Gupta
why we declare it as static “private static StaticBlockSingleton instance” what would go wrong if we declare it as non static
- Sunny