Thread Safety in Java Singleton Classes

Filed Under: Design Patterns

Singleton is one of the most widely used creational design pattern to restrict the object created by applications. If you are using it in a multi-threaded environment, then the thread-safety of the singleton class is very important.

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. We can create a wrapper class for the resource and limit the number of objects created at runtime to one.

Thread Safe Singleton in Java

thread safe singleton in java

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

  1. Create 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.

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, the getInstance() method is not thread-safe.

Multiple threads can access it at the same time. For the first few threads when the instance variable is not initialized, multiple threads can enter the if loop and create multiple instances. It will break our singleton implementation.

How to achieve thread-safety in Singleton Class?

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

  1. Create the instance variable at the time of class loading.
  2. Pros:

    • Thread safety without synchronization
    • Easy to implement


    • 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.
  3. Synchronize the getInstance() method.
  4. Pros:

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


    • Slow performance because of locking overhead.
    • Unnecessary synchronization that is not required once the instance variable is initialized.
  5. Use synchronized block inside the if loop and volatile variable
  6. 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.


    • Extra if condition

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

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;


The 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 if the thread-safety is compromised in the above implementation, please comment and share it with all of us.

Bonus Tip

String is not a very good candidate to be used with synchronized keyword. It’s because they are stored in a string pool and we don’t want to lock a string that might be getting used by another piece of code. So I am using an Object variable. Learn more about synchronization and thread safety in java.

You can checkout more Java examples from our GitHub Repository.


  1. sakshi says:

    Hi, I did not understood the use of result variable, and how it is helping in improve performance by 25%

  2. Sagar Solanki says:

    What is the use of mutex Object here sir i cannot understand.

  3. Kshitiz Gupta says:

    I didn’t understand this part “Local variable result seems unnecessary” and the explanation you gave. Could you elaborate please?

  4. Pallavi Singh says:

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

  5. Deepak says:

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


  6. 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
    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

  7. 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;

    protected Object clone() throws CloneNotSupportedException {
    throw new CloneNotSupportedException();


  8. 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.

  9. ashish gupta says:

    public class TestSingleton {

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

    ASingleton singleton2 = ASingleton.getInstance();

    Constructor c = ASingleton.class.getDeclaredConstructor((Class[]) null);

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

    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 –

  10. Parvesh Kumar says:

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

  11. 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;

  12. 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.

  13. 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.

  14. 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(){
    throw new InstantiationError( “Creating of this object is not allowed.” );

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

    What do you think?



  15. 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()

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

    refer to:

    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.

  16. 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)

  17. jubi max says:

    Thank you very much

  18. 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.


    1. Nayanava says:

      by object do you mean the mutex object??

    2. Raviraj_bk says:

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

  19. Ravi says:

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

  20. Hamid Khan says:

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

  21. 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

  22. 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;


  23. DIVYA PALIWAL says:


    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.


  24. Praful says:

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

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

  26. 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.

  27. 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.

  28. Asanka says:

    Hi Pankaj,

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

    1. Pankaj says:

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

  29. 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 {


    // 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

  30. Hesham says:

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

  31. Anonymous says:

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

  32. 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.

  33. 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.

Comments are closed.

Generic selectors
Exact matches only
Search in title
Search in content