Why in this getInstance synchronized to do?

This is a singleton class for working with the network using retrofit.

public static NetworkWorker getInstance(){ if (networkWorker == null){ synchronized (NetworkWorker.class) { if (networkWorker == null) { networkWorker = new NetworkWorker(); } } } return networkWorker; }
  • Why in this example, two checks for null? - Werder
  • one
    well, probably so that no two instances of NetworkWorker appear ... does it not follow from the pattern used - ermak0ff
  • @Werder I do not know. I did not write) I saw an example - I want to know why. - researcher
  • @ ermak0ff I have never used synchronized .. and I don’t understand how it works. Well, why is he in singleton - xs. You can also write if (worker == null) {create worker;} or return worker; correct if I am mistaken. thank! - researcher
  • Good article on the topic - habrahabr.ru/post/27108 . At the end of the article it is written how to write a synchronized singleton - Werder

2 answers 2

When implementing a singleton even with synchronized, there are cases where when using multithreading, threads can create a single instance class twice - which is unacceptable for the implementation of the pattern.

Synchronized is needed, so that only one thread can work in the method / object at the moment, and the rest are waiting for the work to finish. This is essentially a lineup.

If it were just a class that needs to be protected by a synchronized screen - then there would be one check for null, but since here the implementation of the singleton is going on, then we need to do two checks.

  • Thanks for the detailed answer! - researcher
  • It also needs the use of a local variable to provide for everything. And the monitor, not the screen. - DanielOlivo
  • @DanielOlivo is it possible in more detail about a local variable? - researcher
  • one
    @researcher here is the screen joxi.ru/ZrJdXX7h1PEKd2 with pseudocode. Local variable in order to prevent the creation of an instance in the moment between conditional and synchronization in another thread. In this case, a situation may arise in which two streams validly receive two different instances, despite the monitor. - DanielOlivo

The pattern is called Double checked locking. It is designed in the case of lazy initialization to eliminate expensive synchronization (in the case when getInstance is declared synchronous), which is needed only when several threads apply for the instance at the time of its initialization, no synchronization is needed during subsequent calls.

Proper implementation of this pattern is full of problems: and happens before (when the object reference is available outside the critical section until the end of initialization) and performance degradation due to volatile ...

If the situation allows, then it is more correct to create a singleton immediately upon announcement. Or to guarantee the launch of threads strictly after the initialization of the singleton, while DCL is useless.

  • I looked at the class code through which various server requests are made and there is this piece of code. I will re-read your answer and try to figure out how to properly implement a singleton for this class. Thank! - researcher