All About Singleton Pattern

What is Singleton Pattern?

The Single Pattern is the simplest design pattern. Many times it’s important to have only one instance for a particular class, for example we need to provide configuration manager for all the configurations of our application. But, we need to restrict instantiation of configuration manager class to only one. So only one instance of configuration manager will serve all the requests for configuration of our application. To better understand the scenario following is pseudo code.

if(configurationManagerInstance == null)
	configurationManagerInstance = new ConfigurationManager();
return configurationManagerInstance;

Whenever any request arrives that demands configuration settings of our application, one instance of configuration manager will serve the request. If this is the first request it will going to instantiate the configuration manager instance otherwise it will return already instantiated configuration manager instance.

What Singleton Pattern Ensures?

Single Pattern ensures following things.

  • It ensures that instance is created only once.
  • It ensures that instance will never be null.
  • It ensures that instance will be thread safe.
  • Instance uses little memory.
  • Provides lazy instantiation.
  • Class is freezes for sub-classing and instantiation.

Implementation of a Singleton Pattern

The implementation of a singleton pattern involves a static member inside “sealed” public singleton class with a private constructor and a static public method GetInstance() which returns a reference to the static member (which holds only single instance of the class).



UML Diagram of Singleton Pattern


The GetInstance() method is responsible for returning single instance of the class. If the static member is null it will instantiate the static member. The instantiation is done inside the GetInstance() method thus it needs to be thread safe.

//sealed to make sure it's not inheritable
public sealed class singleton
{
	//static member to ensure single placeholder for object throughout scope of the class
	private static singleton instance;
	//used for locking block of code
	private static readonly object locker = new object();
	
	//private constructor to restrict direct instantiation of the class
	private singleton() { }
	
	public static singleton GetInstance()
	{
		//synchronization lock, only one thread will enter the block
		lock(locker)
		{
			if(instance == null)
				instance = new singleton();
		}
		return instance;
	}
	
	/*
	public void OtherMethods() { }
	*/
}

When Singleton Pattern is Preferred?

  • Singleton is preferred over global variables because it allows lazy allocation and instantiation. It also consumes resources only when required compare to global variables which in many languages always consume resources even if not required.
  • The other scenario where singleton pattern preferred is in case of “heavy” objects or factories. If our object is large which takes reasonable amount of memory we normally wish to instantiate only one object. In case of implementing factories we also wish to provide single instance of the factory.

Why Singleton? Not Static Class

  • Because singleton don’t require to use the static keyword everywhere, it preserves the conventional class approach.
  • Because singleton can implement interfaces or can be derived from base classes if required.
  • Because singletons can be used as parameters or objects.

Examples

  • Load Balancer Classes
  • Configuration Classes
  • Common Shared Resource Classes (printer class, scanner class, etc)
  • Logger Classes (logging framework)
  • Factories (session factories)
  • DBMS classes

Implementation Scenarios

Multi-threading Implementation  :  

In multi-threaded usage, multiple threads are simultaneously accessing singleton class. If the instantiation is not thread-safe then there might be the chances that two threads holding difference instance object for same singleton class, which will spoil the purpose of singleton pattern. So, while implementing singleton pattern it is common practice to make the object instantiation logic thread-safe. Previous example shows basic thread-safe implementation in csharp.

Protected Constructor  :  

Normally, the constructor of a singleton class implementation is private. But in scenario where subclassing of a singleton class is needed we can keep constructor of a singleton class as private. There are drawbacks associated with this kind of implementation.

  • Protected constructor means, the class can be instantiated through calling the constructor from another class within the same namespace. Solution to the problem is creating separate namespace for singleton class implementation purpose.
  • For using derived class, we need to change GetInstance calls from Singleton.GetInstance() to NewSingleton.GetInstance().

Implementation Using Static Field (Early Instantiation)  :  

In previous code example, singleton class is instantiated in synchronized block only when it calls GetInstance() for the first time. If we need to ensure instantiation when the class is loaded, not when it is called first time GetInstance() method (called Early Instantiated) then we can achieve this using static fields instantiated directly which declared.

//sealed to make sure it's not inheritable
public sealed class singleton
{
	//static member to ensure single placeholder for object throughout scope of the class
	//Early Instantiation
	private static singleton instance = GetInstance();
	
	//private constructor to restrict direct instantiation of the class
	private singleton() { }
	
	//no need of synchronized block to make it thread safe
	public static singleton GetInstance()
	{
		if(instance == null)
			instance = new singleton();
		return instance;
	}
	
	/*
	public void OtherMethods() { }
	*/
}

Double Locking Implementation (Lazy Instantiation)  :  

The idea behind the double is to avoid costly synchronization for every invocations of the GetInstance() method. The cost of synchronization differs from compiler to compiler and even as the compilers are evolved the cost of synchronization decreases. But, it still affects performance, it still costs performance. So application developers never want to waste processing time whenever possible. Double locking is implementation for the same.

//sealed to make sure it's not inheritable
public sealed class singleton
{
	//static member to ensure single placeholder for object throughout scope of the class
	private static singleton instance;
	//used for locking block of code
	private static readonly object locker = new object();
	
	//private constructor to restrict direct instantiation of the class
	private singleton() { }
	
	//synchronized block needed if instance is null
	public static singleton GetInstance()
	{
		if(instance == null)
		{
			//synchronization lock, only one thread will enter the block
			lock(locker)
			{
				//double checking for nullability of instance object
				if(instance == null)
					instance = new singleton();
			}
		}
		return instance;
	}
	
	/*
	public void OtherMethods() { }
	*/
}

Now lets dry run the double locking algorithm.
Step 1. First thread enters the GetInstance() method.
Step 2. First thread enters the synchronized block because instance is null.
Step 3. Now second thread comes into the picture. Second thread enters the GetInstance() method.
Step 4. Second thread tries to acquire the lock, but since the first thread holds the lock second thread waits.
Step 5. First thread continues execution. The instance is null so it creates a singleton object and assigns to instance variable.
Step 6. First thread exits the synchronization block and returns instance from the GetInstance() method.
Step 7. Since synchronized block is no longer blocked by any other thread second thread continues execution.
Step 8. Second thread acquires the synchronization lock and checks whether instance is null or not.
Step 9. The instance is not null so rather than creating second instance created it will return the instance already created by first thread.
(In single locking case second thread at Step 8. will found instance null and create another instance, which would break singleton pattern)

So, this is how double locking implementation works.

Out Of Order Writes

Final scenario we discuss is out of order writes. It is basically dealt with the synchronization between object instantiation and calling of construction of singleton class to make instantiation complete. Let’s again dry run double locking algorithm with some different aspect in mind.

Step 1: First thread enters GetInstance() method and found instance is null.
Step 2: First thread enters synchronization block and found again instance is null.
Step 3: Since first thread founds instance null inside the synchronization block it will instantiate instance object, but still the constructor of Singleton class is not executed.
Step 4: Second thread comes into the picture, and checks if instance is null.
Step 5: Since instance is already instantiated by first thread second thread found instance not null.
Step 6: So, second thread will return instance object instantiated by first thread but it is partially initialized Singleton object.
Step 7: First thread continues execution by completing initialization of the Singleton object by executing it’s constructor and returns with instance object.

So, in above dry run double locking mechanism breaks. The situation here we generated by above dry run is called out-of-order writes.

To avoid out-of-order write problem we need to introduce local variable instance1 and second synchronization block. Sample code is shown below.

//sealed to make sure it's not inheritable
public sealed class singleton
{
	//static member to ensure single placeholder for object throughout scope of the class
	private static singleton instance;
	//used for locking first synchronization block of code
	private static readonly object locker = new object();
	//used for locking second synchronization block of code
	private static readonly object locker1 = new object();
	
	//private constructor to restrict direct instantiation of the class
	private singleton() { }
	
	//synchronized block needed if instance is null
	public static singleton GetInstance()
	{
		if(instance == null)
		{
			//first synchronization lock, only one thread will enter the block
			lock(locker)
			{
				Singleton instance1 = instance;
				if(instance1 == null)
				{
					//second level synchronization lock, only one thread will enter the block
					lock(locker1)
					{
						instance1 = new singleton();
					}
					instance = instance1;
				}
			}
		}
		return instance;
	}
	
	/*
	public void OtherMethods() { }
	*/
}

Let’s dry run above algorithm to check whether it addresses out-of-order write scenario or not.
Step 1: First thread enters GetInstance() method.
Step 2: The instance object is null, so it enters the first synchronization block and assign instance1 the value of instance which is null right now.
Step 3: First thread now checks the value of instance1 which is null so enters second synchronization block and instantiate instance1 but constructor execution is still pending execution.
Step 4: Now, second thread comes into the picture. Second thread enters into the GetInstance method and checks whether instance is null or not.
Step 5: Since instance is still null (first thread still not assign initialized object to instance, it’s still reference initialized object to instance1),
second thread tries to enter first synchronization block but since first thread is holding the lock second thread not able to enter first synchronization block.
Step 6: First thread completes execution by assigning fully constructed object instance1 to instance and leaves both synchronization blocks and returns fully constructed instance object.
Step 7: Second thread will get the access to first synchronization block and assigns instance object reference which is now not null to instance1.
Step 8: Now, while checking not null of instance1, second thread will found it’s not null and already initialized. So, second thread will not enter the second synchronization block.
Step 9: Second thread returns fully constructed instance object.

There are some optimizations also possible to the above algorithm, but this is the basic algorithm which addresses both double-checked locking scenario as well as out-of-order writes scenario.

References

OODesign
Double-checked locking and the Singleton pattern

All About Singleton Pattern
2 votes, 3.50 avg. rating (76% score)

2 Comments

  1. Shivesh

    I was looking for singleton related resource which can make concept clear and as much I was reading, I was getting confused.
    But, after reading this blog, singleton is crystal clear. You have done a great job here. Thanks a lot.

    Reply

  2. Aliasgar

    Thanx very nice and easy explanation.

    Reply

Leave a Reply

*


*