Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Java Singleton and Synchronization

Please clarify my queries regarding Singleton and Multithreading:

  • What is the best way to implement Singleton in Java, in a multithreaded environment?
  • What happens when multiple threads try to access getInstance() method at the same time?
  • Can we make singleton's getInstance() synchronized?
  • Is synchronization really needed, when using Singleton classes?
like image 588
RickDavis Avatar asked Jun 23 '12 00:06

RickDavis


People also ask

Is singleton class synchronized in java?

To make a singleton class thread safe, getInstance() method is made synchronized so that multiple threads can't access it simultaneously.

How thread synchronization is achieved for a singleton object?

Thread Safe Singleton in JavaCreate the private constructor to avoid any new object creation with new operator. Declare a private static instance of the same class. Provide a public static method that will return the singleton class instance variable.

Is singleton object thread safe in java?

Is singleton thread safe? A singleton class itself is not thread safe. Multiple threads can access the singleton same time and create multiple objects, violating the singleton concept. The singleton may also return a reference to a partially initialized object.

What is the disadvantage of Singleton pattern in java?

Singletons hinder unit testing: A Singleton might cause issues for writing testable code if the object and the methods associated with it are so tightly coupled that it becomes impossible to test without writing a fully-functional class dedicated to the Singleton.


2 Answers

Yes, it is necessary. There are several methods you can use to achieve thread safety with lazy initialization:

Draconian synchronization:

private static YourObject instance;  public static synchronized YourObject getInstance() {     if (instance == null) {         instance = new YourObject();     }     return instance; } 

This solution requires that every thread be synchronized when in reality only the first few need to be.

Double check synchronization:

private static final Object lock = new Object(); private static volatile YourObject instance;  public static YourObject getInstance() {     YourObject r = instance;     if (r == null) {         synchronized (lock) {    // While we were waiting for the lock, another              r = instance;        // thread may have instantiated the object.             if (r == null) {                   r = new YourObject();                 instance = r;             }         }     }     return r; } 

This solution ensures that only the first few threads that try to acquire your singleton have to go through the process of acquiring the lock.

Initialization on Demand:

private static class InstanceHolder {     private static final YourObject instance = new YourObject(); }  public static YourObject getInstance() {     return InstanceHolder.instance; } 

This solution takes advantage of the Java memory model's guarantees about class initialization to ensure thread safety. Each class can only be loaded once, and it will only be loaded when it is needed. That means that the first time getInstance is called, InstanceHolder will be loaded and instance will be created, and since this is controlled by ClassLoaders, no additional synchronization is necessary.

like image 163
Jeffrey Avatar answered Oct 07 '22 07:10

Jeffrey


This pattern does a thread-safe lazy-initialization of the instance without explicit synchronization!

public class MySingleton {       private static class Loader {          static final MySingleton INSTANCE = new MySingleton();      }       private MySingleton () {}       public static MySingleton getInstance() {          return Loader.INSTANCE;      } } 

It works because it uses the class loader to do all the synchronization for you for free: The class MySingleton.Loader is first accessed inside the getInstance() method, so the Loader class loads when getInstance() is called for the first time. Further, the class loader guarantees that all static initialization is complete before you get access to the class - that's what gives you thread-safety.

It's like magic.

It's actually very similar to the enum pattern of Jhurtado, but I find the enum pattern an abuse of the enum concept (although it does work)

like image 36
Bohemian Avatar answered Oct 07 '22 06:10

Bohemian