Please clarify my queries regarding Singleton and Multithreading:
getInstance()
method at the same time?getInstance() synchronized?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.
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.
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.
Draconian synchronization and Double check synchronization getInstance()-method must be static! –
Sino static, but it might make more sense if they were. Amended as requested. –
Bebop wait on the lock. –
Bebop static inner class, otherwise it will not work. This will generate another *.class file at compilation time, and a class loading overhead when you first access your singleton. –
Bebop YourObject.class. It's always safer to use a private lock object because then you know exactly when and where the monitor will be grabbed –
Bebop InstanceHolder must be a separate class? public class Foo { private static Foo f = new Foo(); public static Foo getInstance() {return f;} What's wrong with this? –
Zarzuela r is not needed for correctness. It's just an optimization to avoid accessing the volatile field, since that's far more expensive than accessing a local variable. –
Bebop synchronized block ensure that the non-cached values of the fields will be retrieved, meaning that the volatile part is not needed anymore ? Is this still required even today? –
Thresathresh synchronized block is more expensive than accessing a volatile variable. Making the variable volatile means we get to skip entering the synchronized block at all after the singleton has been initialized. –
Bebop volatile is only good for performance of first access , and not for better thread-safety as I've read on some places? Also, isn't this a relatively tiny boost, as it's only for current threads, and only for the case that they are before the synchronized part and it's being updated now? Meaning it's a very specific thing, no? –
Thresathresh volatile to ensure thread safety/memory consistency. It's good for performance for all accesses after the singleton has been initialized. It is not a tiny boost. –
Bebop volatile to improve the performance of a such a solution while ensuring thread safety. –
Bebop 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)
static final MySingleton INSTANCE? –
Regressive final should be added. Done. –
Calcariferous MySingleton constructor inside the inner class if the getInstance method requires a parameter? –
Golconda public static MySingleton getInstance(Object param) {...}? –
Calcariferous param to MySingleton if the constructor requires param? –
Golconda If you are working on a multithreaded environment in Java and need to gurantee all those threads are accessing a single instance of a class you can use an Enum. This will have the added advantage of helping you handle serialization.
public enum Singleton {
SINGLE;
public void myMethod(){
}
}
and then just have your threads use your instance like:
Singleton.SINGLE.myMethod();
Yes, you need to make getInstance() synchronized. If it's not there might arise a situation where multiple instances of the class can be made.
Consider the case where you have two threads that call getInstance() at the same time. Now imagine T1 executes just past the instance == null check, and then T2 runs. At this point in time the instance is not created or set, so T2 will pass the check and create the instance. Now imagine that execution switches back to T1. Now the singleton is created, but T1 has already done the check! It will proceed to make the object again! Making getInstance() synchronized prevents this problem.
There a few ways to make singletons thread-safe, but making getInstance() synchronized is probably the simplest.
Enum singleton
The simplest way to implement a Singleton that is thread-safe is using an Enum
public enum SingletonEnum {
INSTANCE;
public void doSomething(){
System.out.println("This is a singleton");
}
}
This code works since the introduction of Enum in Java 1.5
Double checked locking
If you want to code a “classic” singleton that works in a multithreaded environment (starting from Java 1.5) you should use this one.
public class Singleton {
private static volatile Singleton instance = null;
private Singleton() {
}
public static Singleton getInstance() {
if (instance == null) {
synchronized (Singleton.class){
if (instance == null) {
instance = new Singleton();
}
}
}
return instance ;
}
}
This is not thread-safe before 1.5 because the implementation of the volatile keyword was different.
Early loading Singleton (works even before Java 1.5)
This implementation instantiates the singleton when the class is loaded and provides thread safety.
public class Singleton {
private static final Singleton instance = new Singleton();
private Singleton() {
}
public static Singleton getInstance() {
return instance;
}
public void doSomething(){
System.out.println("This is a singleton");
}
}
You can also use static code block to instantiate the instance at class load and prevent the thread synchronization issues.
public class MySingleton {
private static final MySingleton instance;
static {
instance = new MySingleton();
}
private MySingleton() {
}
public static MySingleton getInstance() {
return instance;
}
}
instance final 2. You should make getInstance() static. –
Dilantin What is the best way to implement Singleton in Java, in a multithreaded environment?
Refer to this post for best way to implement Singleton.
What is an efficient way to implement a singleton pattern in Java?
What happens when multiple threads try to access getInstance() method at the same time?
It depends on the way you have implemented the method.If you use double locking without volatile variable, you may get partially constructed Singleton object.
Refer to this question for more details:
Why is volatile used in this example of double checked locking
Can we make singleton's getInstance() synchronized?
Is synchronization really needed, when using Singleton classes?
Not required if you implement the Singleton in below ways
Refer to this question fore more details
public class Elvis {
public static final Elvis INSTANCE = new Elvis();
private Elvis () {...}
}
Source : Effective Java -> Item 2
It suggests to use it, if you are sure that class will always remain singleton.
© 2022 - 2024 — McMap. All rights reserved.