Using synchronized getInstance() method – Naive Approach

So how can we prevent creation of multiple instances in above approach? Easiest way to achieve this is by making getInstance() method thread-safe using synchronized keyword as shown below.

public class ThreadSafeSingleton {
	private static ThreadSafeSingleton instance;

	private ThreadSafeSingleton() {
	}

	// Thread T2, T3, T4 are waiting for T1 to release the lock
	public static synchronized ThreadSafeSingleton getInstance() {
		// Thread T1 has taken the lock
		if (instance == null) {
			instance = new ThreadSafeSingleton();  // Critical section
		}
		return instance;
	}
}

Download Complete Java Program »

This will solve our problem. But it leads us to bad performance as only one thread can access getInstance() method at a time even though critical section is only one line (line 11) where instance is being created. 

For Example, In above code, as Thread T1 is inside getInstance() method, other threads T2, T3, T4 has to wait until T1 completes its execution of getInstance() method. It reduces performance drastically. 

Double Checked Locking

In above approach, we need to bear cost of synchronization all the time we call getInstance() method,  but synchronization is only needed on first call when Singleton instance is created.

To improve the performance, lets modify the code of getInstance() method. Instead of declaring entire method synchronized, now we will just include critical section inside synchronized block as shown below:

public static DoubleCheckedLockingSingleton getInstance() 
{
	if (instance == null) 
	{
		synchronized (DoubleCheckedLockingSingleton.class) 
		{
			instance = new DoubleCheckedLockingSingleton();
		}

	}
	return instance;
}

Will this improve the performance?

Yes. If instance has already been created, then threads will not enter the if block and directly return instance. They don't have to wait for lock on synchronized block.

Is it thread-safe? Can you think of any situation which can result into creation of multiple instances?

Here is the case in which singleton design pattern will break with this approach :

package com.codepumpkin.creational.singleton;

public class DoubleCheckedLockingSingleton {

    // this field should be volatile to avoid half baked object creation
	private static DoubleCheckedLockingSingleton instance;   

	private DoubleCheckedLockingSingleton() 
	{
       // 10000 lines of initialization code
	}

	public static DoubleCheckedLockingSingleton getInstance() 
	{
		if (instance == null) 
		{
			synchronized (DoubleCheckedLockingSingleton.class) 
			{
				if (instance == null) 
				{
					instance = new DoubleCheckedLockingSingleton();
					System.out.println("Instance Created");
				}
			}

		}
		return instance;
	}

}

Above code looks perfectly fine and it should work correctly, right? Unfortunately, there is no guarantee it will work correctly on all JVM and it may fail in some.  

Issue is not with the JVM or our code, but it is with the Java Memory model and the way java code compiles using some of the JIT Compilers. The Java memory model allows what is known as "out-of-order writes" and it is a prime reason for this issue.

What is "out-of-order writes"?

To understand this better, lets look at the process of object creation in Java. Here are the steps which are being followed by most of the compilers.

1. Allocating a memory to the object
2. execute the code inside constructor 
3. Assigning memory reference to the field

Problem is with some of the JIT compilers which reorders step 2 and step 3 in above instructions. To understand how this occurs, consider the following pseudo code for the line:

instance = new DoubleCheckedLockingSingleton();

Pseudo Code

//Allocate memory for Singleton object.
mem = allocate();             

//Note that instance is now non-null, but has not been initialized. 
instance = mem;              

//Invoke constructor for Singleton passing instance.
invokeDoubleCheckedLockingSingletonConstructor(instance); 

So, when object will be created, instance variable will be assigned non-null reference and then rest of the code inside constructor will be executed.

What is Half Baked Object?

If Object was assigned non-null reference and code inside that constructor is still being executed, then that object is not fully constructed or baked and is referred as Half Baked Object.

How Double Checked Locking pattern returns Half Baked Object?

Refer Below code. I have replaced line instance = new DoubleCheckedLockingSingleton();  with pseudo code for better understanding.

public static DoubleCheckedLockingSingleton getInstance() 
{
	if (instance == null)   // Thread T2 
	{
		synchronized (DoubleCheckedLockingSingleton.class) 
		{
			if (instance == null) 
			{
				// pseudo code for instance = new DoubleCheckedLockingSingleton();
				mem = allocate();             
				instance = mem;              
				invokeDoubleCheckedLockingSingletonConstructor(instance);  // Thread T3
			}
		}
	}
	return instance;
}

Assume that Thread T1 is executing line 12 i.e. it has assigned non-null reference to instance variable, but it has not completed executing code written inside constructor.

At the same time Thread T2 entered getInstance() method and reached at line 3 i.e. outer null-check. As instance is already been assigned, it will not enter the if block and returns half baked object.

Solution to Half Baked Object Issue using volatile

Above problem can be solved by declaring instance field as volatile. However, it will not work in JDK 1.4 and earlier versions.

private static volatile DoubleCheckedLockingSingleton instance;

In JDK 1.5, Some modifications were done in Java Memory Model and behavior of volatile and final fields. From JDK 1.5, The volatile prevents memory writes from being re-ordered, making it impossible for other threads to read uninitialized fields of your singleton through the singleton's pointer.

In other words, when field is declared as volatile, JVM guarantees completion of all those three steps of object creation (refer pseudo code) before another thread reads the reference from instance variable.  This is also known as Happens-Before relationship of volatile field which was introduced in JDK 1.5.