Thread Safety in Java Singleton Classes with Example Code

Filed Under: Design Patterns

Singleton is one of the most widely used creational design pattern to restrict the object creation by applications. In real-world applications, resources like Database connections or Enterprise Information Systems (EIS) are limited and should be used wisely to avoid any resource crunch. To achieve this, we can implement a Singleton design pattern to create a wrapper class around the resource and limit the number of objects created at runtime to one.

Thread Safe Singleton in Java

thread safe singleton, thread safe singleton in java

In general, we follow the below steps to create a singleton class:

  1. Override the private constructor to avoid any new object creation with new operator.
  2. Declare a private static instance of the same class.
  3. Provide a public static method that will return the singleton class instance variable. If the variable is not initialized then initialize it or else simply return the instance variable.

Using the above steps I have created a singleton class that looks like below:

ASingleton.java


package com.journaldev.designpatterns;

public class ASingleton {

	private static ASingleton instance = null;

	private ASingleton() {
	}

	public static ASingleton getInstance() {
		if (instance == null) {
			instance = new ASingleton();
		}
		return instance;
	}

}

In the above code, getInstance() method is not thread-safe. Multiple threads can access it at the same time and for the first few threads when the instance variable is not initialized, multiple threads can enters the if loop and create multiple instances and break our singleton implementation.

There are three ways through which we can achieve thread safety.

  1. Create the instance variable at the time of class loading.

    Pros:

    • Thread safety without synchronization
    • Easy to implement

    Cons:

    • Early creation of resource that might not be used in the application.
    • The client application can’t pass any argument, so we can’t reuse it. For example, having a generic singleton class for database connection where client application supplies database server properties.
  2. Synchronize the getInstance() method

    Pros:

    • Thread safety is guaranteed.
    • Client application can pass parameters
    • Lazy initialization achieved

    Cons:

    • Slow performance because of locking overhead.
    • Unnecessary synchronization that is not required once the instance variable is initialized.
  3. Use synchronized block inside the if loop and volatile variable

    Pros:

    • Thread safety is guaranteed
    • Client application can pass arguments
    • Lazy initialization achieved
    • Synchronization overhead is minimal and applicable only for first few threads when the variable is null.

    Cons:

    • Extra if condition

Looking at all the three ways to achieve thread safety, I think the third one is the best option and in that case, the modified class will look like:


package com.journaldev.designpatterns;

public class ASingleton {

	private static volatile ASingleton instance;
	private static Object mutex = new Object();

	private ASingleton() {
	}

	public static ASingleton getInstance() {
		ASingleton result = instance;
		if (result == null) {
			synchronized (mutex) {
				result = instance;
				if (result == null)
					instance = result = new ASingleton();
			}
		}
		return result;
	}

}

Local variable result seems unnecessary. But it’s there to improve the performance of our code. In cases where the instance is already initialized (most of the time), the volatile field is only accessed once (due to “return result;” instead of “return instance;”). This can improve the method’s overall performance by as much as 25 percent.

If you think there are better ways to achieve this or the thread safety is compromised in the above implementation, please comment and share with all of us.

Update: String is not a very good candidate to be used with synchronized keyword because they are stored in string pool and we don’t want to lock a string that might be getting used by another piece of code, so I have updated it with Object, learn more about synchronization and thread safety in java.

You can checkout more Java examples from our GitHub Repository.

Comments

  1. Pallavi Singh says:

    Isn’t static inner helper class approach better than the above three mentioned?

  2. Deepak says:

    Hi Pankaj,
    How to execute your Singleton class.
    Where is the main method ?

    Deepak

  3. Harshit Joshi says:

    Hey Nice Solution but i think we can also optimize is by not creating object lock instead of it we can use class lock
    example
    Copied!
    package com.journaldev.designpatterns;

    public class ASingleton {

    private static volatile ASingleton instance;
    private ASingleton() {
    }

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

    }

    I am not sure Please guide me as i am fresher

  4. Datta says:

    This seems ok..create instance on class loading and later return same instance..No synchronization required.

    public class Singleton {
    private static Singleton singltonInstance = new Singleton();

    private Singleton() {
    }

    public static Singleton getInstance() {
    return singltonInstance;
    }

    @Override
    protected Object clone() throws CloneNotSupportedException {
    throw new CloneNotSupportedException();
    }

    }

  5. jatin says:

    You don’t talk about enum. Enum objects are best suited for singleton classes. It covers both concurrency and serialization issues we face in our custom singleton classes.

  6. ashish gupta says:

    public class TestSingleton {

    public static void main(String[] args) throws NoSuchMethodException, SecurityException, InstantiationException,
    IllegalAccessException, IllegalArgumentException, InvocationTargetException {
    ASingleton singleton1 = ASingleton.getInstance();
    System.out.println(singleton1);

    ASingleton singleton2 = ASingleton.getInstance();
    System.out.println(singleton2);

    Constructor c = ASingleton.class.getDeclaredConstructor((Class[]) null);
    c.setAccessible(true);
    System.out.println(c);

    ASingleton singleton3 = c.newInstance((Object[]) null);
    System.out.println(singleton3);

    if (singleton1 == singleton2) {
    System.out.println(“Variable 1 and 2 referes same instance”);
    } else {
    System.out.println(“Variable 1 and 2 referes different instances”);
    }
    if (singleton1 == singleton3) {
    System.out.println(“Variable 1 and 3 referes same instance”);
    } else {
    System.out.println(“Variable 1 and 3 referes different instances”);
    }
    }

    }

    Hi Pankaj,

    NIce article,
    but the solution you provided , fails the above testcase.

    Thanks .

    1. Gandalf says:

      The test case you have mentioned uses Java Reflection API which is not used by the same code base for most cases. Imagine an app that wants to keep the constructor private and still uses reflection to access the private constructor at other place, if that’s the case, then why make the constructor private in the first place? So generally speaking the developer of an app that uses private members won’t break his own rules to use Java reflection to access private constructors. Now, let’s take the case of third party apps accessing a common library that uses singletons. Now as a developer using the common library, you wanna use it in the proper way rather than using reflection so that your app performs better and your threads do not accidentally create multiple instances of the limited resource.

      The purpose of data encapsulation and other Object oriented programming methodology is for encouraging loose coupling and other best practices, these rules are not related to security to prevent something from happening. Its your code, you can do anything with it. These principles are for us developers to follow to ensure our app is maintainable in the long run. If we purposefully decide to not use these principles, then no one is there to restrict us.

      Now in case, let’s say we are suspicious about our own developers going out of the way and using reflection which is a rare case but still, then the solution is to run Java app with certain security policies that restrict the reflection capabilities. Read more here – https://stackoverflow.com/questions/7566626/how-to-restrict-developers-to-use-reflection-to-access-private-methods-and-const

  7. Parvesh Kumar says:

    The third option is not a singlton class it will create new instance always.

  8. AB says:

    C++ implementation using a bool var instead (possibly more efficent)

    static ConnectionManager *_currentInstance = nullptr;
    static bool instanceAvailable = false;
    static std::mutex singletonMutex;

    ConnectionManager* ConnectionManager::getInstance()
    {
    // thread safe implementation of SINGLETON
    if (!instanceAvailable)
    {
    instanceAvailable = true;
    std::unique_lock lck(singletonMutex);
    if (!_currentInstance) {
    _currentInstance = new ConnectionManager;
    }
    }
    return _currentInstance;
    }

  9. Diego says:

    Thanks Pankaj, great article.
    One question: does adding synchronization at the getInstance level (regardless of the approach) remove the need to synchronize access to other resources in the instance (member variables, class variables and methods)?

    thanks again

    1. Pankaj says:

      No it won’t. When you add synchronization to getInstance method, it is to make sure that you have only one instance of the Singleton class. So if two threads are calling getInstance method, both will get reference to the same object, hence any change in class variables or instance variable will be reflected in other thread as well. So you will have to take care of synchronization for these variables too. Ideally, you should avoid any variables in Singleton class.

  10. Raviraj_bk says:

    we can use “synchronized (ASingleton.class) ” instead of below piece of code
    synchronized (mutex) {
    result = instance;
    if (result == null)
    instance = result = new ASingleton();
    }

    1. Raviraj_bk says:

      is it right?

    2. Pankaj says:

      Synchronizing class will lock it’s object too, that’s why we should always create a temporary variable for synchronizing block of code.

  11. Edo says:

    I think that this kind of implementation doesn’t avoid the singleton creation through reflection.

    My favourite implementation is something like this:

    public class MySingleton {

    private static class Loader {
    private static MySingleton INSTANCE = new MySingleton();
    }

    private MySingleton(){
    if(Loader.INSTANCE!=null){
    throw new InstantiationError( “Creating of this object is not allowed.” );
    }
    }

    public static MySingleton getInstance(){
    return MySingleton.Loader.INSTANCE;
    }
    }

    What do you think?

    Thanks

    Edo

  12. Marton Korosi says:

    I think the 3rd approach is incorrect.

    instance variable should be volatile! like this:
    private static volatile ASingleton instance= null;

    ——–

    If instance variable is not volatile, JVM can reorder
    new ASingleton()
    and
    instance=

    operations which may result in an instance variable which will point to uninitialized memory!

    refer to: https://en.wikipedia.org/wiki/Double-checked_locking

    1. Pankaj says:

      Thanks for pointing it out, it was written long back when volatile was broken in java 1.4. I have updated the code with correct approach now.

  13. Noy says:

    Hi. I have two issues with the selection of the third option. One is that by creating a mutex static object you contradict the fact that you keep a static option that you may never use(mutex).
    Second is that i would change the code to contain the if condition one time unsynchronized and obe time in an inner if when it is synchronized on mutex.

    1. Aarati says:

      As “instance” field is static. So will it make sense to synchronize on (synchronized (ASingleton.class)

  14. jubi max says:

    Thank you very much

  15. Prachi says:

    I replied the same answer to a interviewer but she asked me that object is not created yet since getInstance() is static method who will get object lock in synchronization.

    Thanks,
    Prachi

    1. Nayanava says:

      by object do you mean the mutex object??

    2. Raviraj_bk says:

      Hi,
      Since mutex is static varible it will be initialized during class loading time, and then synchnozization happens on the lock of mutex object.

  16. Ravi says:

    Can we not use the volatile() instead of using synchroniation?

  17. Hamid Khan says:

    You haven’t made any comment regarding why not making ‘instance’ volatile.. any thoughts?

  18. Satya says:

    best to make getInstance() synchronized

    1. Santosh Kumar Kar says:

      If the method is synchronized, where huge threads are calling that method, every thread will have to wait when it’s being used by other thread. Think is it really required when the object is already created and != null? So making method synchronization is not a good idea.

      1. vijay says:

        prevent from cloning is not mentioned

  19. Ganesh says:

    That I really appreciate for this article . I learned good stuff today, and also I red some where below code snipped is very good code for singleton, can you compare with your code in terms pros and cons.

    package com.journaldev.designpatterns;

    public class ASingleton{

    private ASingleton(){
    }

    private static class ASingletonInnerClass{

    private static final ASingleton ASINGLETON= new ASingleton();
    }

    public static ASingleton getInstance(){
    return ASingletonInnerClass.ASINGLETON;
    }

    }

  20. DIVYA PALIWAL says:

    Hi,

    Great article!

    I am trying t understand thread safety in Singleton Pttern.
    Can you please provide and example code where different threads are trying to implement Singleton pattern.

    Thanks,
    Divya

  21. Praful says:

    Very nice article. But if loop wording is not correct, please change it to if condition.

  22. Amey Jadiye says:

    I think making instance volatile make much difference than approach given in post

  23. Archna Sharma says:

    In your third approach, although it checks the value of instance once again within the synchronized block but the JIT compiler can rearrange the bytecode in a way that the reference to instance is set before the constructor has finished its execution.
    This means the method getInstance() returns an object that may not have been initialized completely.

    I think, the keyword volatile can be used for the instance variable. Variables that are marked as volatile get only visible to other threads once the constructor of the object has finished its execution completely.

  24. Naveen J says:

    String is not a very good candidate to be used in synchronization, so I have updated it with Object, learn more about synchronization and thread safety in java

    Why string is not good candidate………. Since its immutable its a good candidate to use in synchronization block right.

    1. Pankaj says:

      We should not use any object that is maintained in a constant pool, for example String should not be used for synchronization because if any other code is also locking on same String, it will try to acquire lock on the same reference object from String pool and even though both the codes are unrelated, they will lock each other.

  25. Asanka says:

    Hi Pankaj,

    I believe this is the best way, it doesn’t use any synchronization at all, provides better performance too.

    http://en.wikipedia.org/wiki/Initialization-on-demand_holder_idiom

    1. Pankaj says:

      Singleton Pattern Approaches – read this article to learn about different ways and their pros-cons.

  26. Rishi Dev Gupta says:

    there is a good way to implement the Singletons, that will look after all the issue and with lesser code

    public enum InputValidatorImpl {

    instance;

    // add some method

    }

    1. Pankaj says:

      there are several ways to implement singleton pattern and Enum is one of the way but we can’t achieve lazy initialization with this. Read more at https://www.journaldev.com/1377/java-singleton-design-pattern-best-practices-with-examples#enum-singleton

  27. Hesham says:

    double check lock is not thread safe in java this issue listed by PDM tool (block synchronizing)

  28. Anonymous says:

    ‘,~ I am really thankful to this topic because it really gives useful information :-`

  29. Ben says:

    you can avoid your extra if condition if you create instance described below,

    Once we declare static, it will refer the same object all the time
    package com.journaldev.designpatterns;
    public class ASingleton{
    private static ASingleton instance= new ASingleton();
    private ASingleton(){ }
    public static synchronized ASingleton getInstance(){
    return instance;
    }
    }

    1. Pankaj says:

      Here you are creating the instance at the time of class loading… what if we are expecting some parameters like DB Connection URL, User, Password to be passed in the getInstance method so that it will be generic.

  30. Example 3 is the traditional double check idiom for lazy initialization. The double check is badly broken in java before version 5. The example you have here is broken also because instance is not declared volatile.

    The best way is to extract the singleton code to a separate class which is guaranteed to be loaded only when the referring class is instantiated.

    For more information see item 71 in “Effective Java” (2nd edition) by Joshua Bloch.

    But you’d better avoid singletons completely.

Leave a Reply

Your email address will not be published. Required fields are marked *

close
Generic selectors
Exact matches only
Search in title
Search in content
Search in posts
Search in pages