Why we should check object == null, and why OurPresident.class is argument?

Pytania dotyczące zadania

Rozwiązane

Hello mates, Why we should check object == null, and why OurPresident.class is argument in synchronized block. What means Class.class <= this small class after dot. I admit I haven't read all the CG material yet maybe there explained?

static {
    synchronized (OurPresident.class) {
        if (president == null) {
            president = new OurPresident();
        }
    }
}

Ze wzorcem projektowym singleton spotykamy się ponownie podczas synchronizacji w bloku statycznym.
Utwórz blok synchronized w bloku statycznym wewnątrz klasy OurPresident.
Wewnątrz bloku synchronized zainicjalizuj president.

Wymagania:

Klasa OurPresident musi mieć prywatne statyczne pole president typu OurPresident.
Klasa OurPresident musi zawierać publiczną statyczną metodę OurPresident getOurPresident().
Klasa OurPresident musi zawierać prywatny konstruktor.
Klasa OurPresident musi posiadać blok statyczny.
Blok statyczny klasy OurPresident musi posiadać blok synchronized.
Blok synchronized musi inicjalizować president.

package pl.codegym.task.task17.task1706; /* Zsynchronizowany prezydent */ public class Solution { public static void main(String[] args) { OurPresident expectedPresident = OurPresident.getOurPresident(); OurPresident ourPresident = OurPresident.getOurPresident(); System.out.println(expectedPresident == ourPresident ); } }

Komentarze (3)

Popularne
Najnowsze
Najstarsze

Musisz się zalogować, aby dodać komentarz

Thomas

Poziom 41 , Bayreuth, Germany

19 lipca, 06:49

rozwiązanie

Why if (president == null)? Because you want to create a singleton and when it is created another task (eventually from another class loader) possibly could interfere the creation process so that in the end client A gets an instance and client B gets another instance of that singleton class. That's why the creation of the instance has to be done thread save and some ways to create singletons do that in a synchronized block. For the thread save creation of singletons you have different possibilities, some are: a) a static variable as holder and creating the instance in a synchronized static block (- even if the object isn't needed later on it is getting created when the class is accessed in any way, + no need for checking if the instance exists when a client requests it) b) a static variable as holder and creating the instance in a static fabric method (advantage and disadvantage are vice versa to option a) c) a static holder class (has none of the above disadvantages and only the advantages - my prefered way) a and b have in common that the creation of the instance happens in a static context. At the time when you create the instance, no other instance of that type exist... so you just can access static methods or run the static block (constructor is private). Because there is no instance of that object at that time you can not use president or any other instance variable for synchronization. There simply is no memory reserved at that time for them. They do not yet exist. So you need to use something different. Creating an object for synchronization does not work. That process also could be interrupted by another task. But what already exists is the class object. That what you have seen above: OurPresident.class

Class clazz = OurPresident.class;

That's an object that's being created when the classloader loads a class.

Thomas

Poziom 41 , Bayreuth, Germany

19 lipca, 07:00

przydatny

They contain information about the class, methods, parameters of the methods, return values, modificators and so on. So this object is existing and that you can use for synchronization. Imagine synchronization as an if condition. The object you use for synchronization has a (imaginary) boolean flag isSynchronized. If a thread enters the synchronized block it checks that object the block is synchronized on. It looks at the boolean and if it is false it can enter and sets it to true. A next thread will do the same, sees the synchronized block is in use and will wait. If the first task leaves the synchronized block, it will set the flag to false again so other threads may enter. The other reason why it has to be the class object: A class object exist only once. So all threads waiting to access a synchronized block need to use that single object and that way only one thread can be the first. If you would synchronize on this (what does not work here), several threads possibly could enter as several objects of that type could exist. Just threads using the same object can not enter.

Robert

Poziom 20 , Debica, Poland

20 lipca, 09:34

Thank You Thomas for explanation, gives me point of view.