Singleton Design Pattern

Singleton Pattern

Singleton pattern is one of the simplest design patterns in Java. This type of design pattern comes under a creational pattern as this pattern provides one of the best ways to create an object.

Sometimes it’s important for some classes to have exactly one instance. There are many objects we only need one instance of them and if we, instantiate more than one, we’ll run into all sorts of problems like incorrect program behavior, overuse of resources, or inconsistent results. You may require only one object of a class, for example, when you are creating the context of an application, or a thread manageable pool, registry settings, a driver to connect to the input or output console, etc. More than one object of that type clearly will cause inconsistency to your program.

The Singleton Pattern ensures that a class has only one instance, and provides a global point of access to it. However, although the Singleton is the simplest in terms of its class diagram because there is only one single class, its implementation is a bit trickier.

Motivation

Sometimes it's important to have only one instance for a class. For example, in a system, there should be only one window manager or only one print spooler. Usually, singletons are used for centralized management of internal or external resources and they provide a global point of access to themselves.

The singleton pattern involves only one class which is required to instantiate itself and to make sure it creates not more than one instance.

At the same time, it provides a global point of access to that instance. In this case the same instance can be accessed from anywhere, making it impossible to directly invoke the constructor each time.

How to create a class using the Singleton Pattern

There are many ways to create such a type of class, but still, we will see how one way is better than the other. 

Let’s start with a simple way. What if, we provide a global variable that makes an object accessible? For example: 

package com.singleton.demonstration; 

public class SingletonEager { 
public static SingletonEager sc = new SingletonEager(); 
}

As we know, there is only one copy of the static variables of a class, we can apply this. As far as, the client code is using this sc static variable it's fine. But, if the client uses a new operator there would be a new instance of this class. To stop the class to get instantiated outside the class, let’s make the constructor of the class private.

package com.singleton.demonstration;


public class SingletonEager {
	public static SingletonEager sc = new SingletonEager();


	private SingletonEager() {
	}

}

Is this going to work? I believe yes. By keeping the constructor private, no other class can instantiate this class. The only way to get the object of this class is by using the sc static variable which ensures only one object is there. But as we know, providing direct access to a class member is not a good idea. We will provide a method through which the sc variable will get access, not directly. 

package com.singleton.demonstration; 


public class SingletonEager {
 private static SingletonEager sc = new SingletonEager(); 
private SingletonEager(){} 
public static SingletonEager getInstance()
  { 
    return sc;
   } 
 } 

So, this is our singleton class which makes sure that only one object of the class gets created and even if there are several requests, only the same instantiated object will be returned. The one problem with this approach is that the object would get created as soon as the class gets loaded into the JVM. If the object is never requested, there would be an object useless inside the memory. It’s always a good approach that an object should get created when it is required. So, we will create an object on the first call and then will return the same object on other successive calls. 

package com.singleton.demonstration;


public class SingletonLazy {
	private static SingletonLazy sc = null;


	private SingletonLazy() {
	}


	public static SingletonLazy getInstance() {
		if (sc == null) {
			sc = new SingletonLazy();
		}
		return sc;
	}

}

In the getInstance() method, we check if the static variable sc is null, then instantiate the object and return it. So, on the first call when sc would be null the object gets created and on the next successive calls, it will return the same object. This surely looks good, doesn’t it? But this code will fail in a multi-threaded environment. Imagine two threads concurrently accessing the class, thread t1 gives the first call to the getInstance() method, it checks if the static variable sc is null and then gets interrupted due to some reason. Another thread t2 calls the getInstance() method successfully passes the if check and instantiates the object. Then, thread t1 gets awake and it also creates the object. At this time, there would be two objects of this class. To avoid this, we will use the synchronized keyword to the getInstance() method. In this way, we force every thread to wait its turn before it can enter the method. So, no two threads will enter the method at the same time. The synchronized comes with a price, it will decrease the performance, but if the call to the getInstance() method isn’t causing a substantial overhead for your application, forget about it. The other workaround is to move to an eager instantiation approach as shown in the previous example.

package com.singleton.demonstration;


public class SingletonLazyMultithreaded {
	private static SingletonLazyMultithreaded sc = null;


	private SingletonLazyMultithreaded() {
	}


	public static synchronized SingletonLazyMultithreaded getInstance() {
		if (sc == null) {
			sc = new SingletonLazyMultithreaded();
		}
		return sc;
	}

}

But if you want to use synchronization, there is another technique known as "double-checked locking" to reduce the use of synchronization. With the double-checked locking, we first check to see if an instance is created and if not, then we synchronize. This way, we only synchronize the first time.

package com.singleton.demonstration;


public class SingletonLazyDoubleCheck {
	private volatile static SingletonLazyDoubleCheck sc = null;


	private SingletonLazyDoubleCheck() {
	}


	public static SingletonLazyDoubleCheck getInstance() {
		if (sc == null) {
			synchronized (SingletonLazyDoubleCheck.class) {
				if (sc == null) {
					sc = new SingletonLazyDoubleCheck();
				}
			}
		}


		return sc;
	}

}

Apart from this, there are some other ways to break the singleton pattern.

• If the class is Serializable.
• If it’s Clonable.
• It can be break by Reflection.
• And also if, the class is loaded by multiple class loaders.

The following example shows how you can protect your class from getting instantiated more than once.

package com.singleton.demonstration;
import java.io.ObjectStreamException;
import java.io.Serializable;


public class Singleton implements Serializable {
	private static final long serialVersionUID = -1093810940935189395L;
	private static Singleton sc = new Singleton();


	private Singleton() {
		if (sc != null) {
			throw new IllegalStateException("Already created.");
		}
	}


	public static Singleton getInstance() {
		return sc;
	}


	private Object readResolve() throws ObjectStreamException {
		return sc;
	}


	private Object writeReplace() throws ObjectStreamException {
		return sc;
	}


	public Object clone() throws CloneNotSupportedException {
		throw new CloneNotSupportedException("Singleton, cannot be clonned");
	}


	private static Class getClass(String classname) throws ClassNotFoundException {
		ClassLoader classLoader = Thread.currentThread().getContextClassLoader();
		if (classLoader == null)
			classLoader = Singleton.class.getClassLoader();
		return (classLoader.loadClass(classname));
	}
}

}

• Implement the readResolve() and writeReplace() methods in your singleton class and return the same object through them.
• You should also implement the clone() method and throw an exception so that the singleton cannot be cloned.
• An "if condition" inside the constructor can prevent the singleton from getting instantiated more than once using reflection.
• To prevent the singleton from getting instantiated from different class loaders, you can implement the getClass() method. The above getClass() method associates the classloader with the current thread; if that classloader is null, the method uses the same classloader that loaded the singleton class. 

Although we can use all these techniques, there is one simple and easier way of creating a singleton class. As of JDK 1.5, you can create a singleton class using enums. The Enum constants are implicitly static and final and you cannot change their values once created.

package com.singleton.demonstration;


public class SingletoneEnum {
	public enum SingleEnum {
		SINGLETON_ENUM;
	}

}

You will get a compile-time error when you attempt to explicitly instantiate an Enum object. As Enum gets loaded statically, it is thread-safe. The clone method in Enum is final which ensures that enum constants never get cloned. Enum is inherently serializable, the serialization mechanism ensures that duplicate instances are never created as a result of deserialization. Instantiation using reflection is also prohibited. These things ensure that no instance of an enum exists beyond the one defined by the enum constants.

When to use Singleton

• There must be exactly one instance of a class, and it must be accessible to clients from a well-known access point.
• When the sole instance should be extensible by subclassing, and clients should be able to use an extended instance without modifying their code.

Pros and Cons of using Singleton

Pros

• You can be sure that a class has only a single instance.
• You gain a global access point to that instance.
• The singleton object is initialized only when it’s requested for the first time.

Cons

• Violates the Single Responsibility Principle. The pattern solves two problems at the time.
• The Singleton pattern can mask bad design, for instance, when the components of the program know too much about each other.
• The pattern requires special treatment in a multithreaded environment so that multiple threads won’t create a singleton object several times.
•  It may be difficult to unit test the client code of the Singleton because many test frameworks rely on inheritance when producing mock objects. Since the constructor of the singleton class is private and overriding static methods is impossible in most languages, you will need to think of a creative way to mock the singleton. Or just don’t write the tests. Or don’t use the Singleton pattern.

Conclusion

In the above article, we have gone into the details of the Singleton pattern, how to implement the singleton pattern along with a practical demonstration. Though the singleton pattern looks like a simple implementation we should resist using it until and unless there is a strong requirement for it. You can blame the unpredictable nature of the results in the multi-threading environment. Though we can use enum in Java 5 and above it sometimes gets difficult to implement your logic always in an enum or there might be legacy code before Java 5.

References

https://www.tutorialspoint.com/design_pattern/singleton_pattern.htm 

https://refactoring.guru/design-patterns/singleton

https://www.gofpatterns.com/design-patterns/module3/singleton-design-pattern-conclusion.php

https://dzone.com/articles/singleton-design-pattern-%E2%80%93

https://www.goodreads.com/book/show/34403757-java-design-patterns

https://www.amazon.com/Java-Design-Patterns-Vaskaran-Sarcar/dp/1484218019