Singleton Pattern in multithreaded environment

Traditional way to implement Singleton in Single threaded environment  may cause of problem of double-checked locking implementation in multi-threaded environment .

Let's have a look , How ??

Singleton1 - which we generally use 

Looking at the implementation of the static method getInstance, first there is a check without synchronization to determine if initialization is needed, if needed then a lock is obtained in case two threads call getInstance concurrently to prevent that both threads attempt to create the object at the same time or one of the threads obtaining a partially initialized object reference.

The problem with this implementation is that once a thread gets the lock and executes the statement instance = new Singleton() a second thread could enter getInstance method and test the first check instance == null that could return false depending on the state of the execution of the first thread and the second thread could obtain a partially initialized Singleton instance.

Another problem is that once the Singleton instance is initialized every thread getting the instance of Singleton calling getInstance will paid the synchronized performance cost.

A better Java Singleton: Initialization on demand class holder Singleton implementation

Now let look at class holder and initialization on demand or lazy loading implementation and how it solves the two problems found with the double-checked locking implementation of the singleton pattern in Java.

Singleton2

How it works:

The key of this implementation relies on the very well specified initialization phase of execution of the Java Virtual Machine.

When the Singleton class is loaded by the JVM the class is initialized but since it doesn’t have any static variables to initialize then it completes without any additional steps executed. The static class definition InstanceHolder that is defined inside Singleton class in line 4 is not intialized until the JVM determines that InstanceHolder must be executed. The static class InstanceHolder is executed only when the static method getInstance is invoked on the class Singleton, and only then the JVM will load and intialize the InstanceHolder class. The intialization of the HolderInstance class then results in static variable ‘instance’ in line 5 being initialized by executing the private constructor for the outer class Singleton. Since the class initialization is guaranteed to be serial (non-concurrent) then no further synchronization is required in the static getInstance method during load and initialization time and since the intialization phase sets the static var singleton in a serial operation all subsequent concurrent invocations of the getInstance method will return the correctly initialized singleton without incurring in synchronization overhead.

Hence the initialization on demand class holder singleton is a more efficient and thread-safe implementation in the Java language.