dlaczego używasz lotnych z zsynchronizowanym blokiem?

Question

Widziałem kilka przykładów w java, gdzie synchronizują się na bloku kodu, aby zmienić pewną zmienną, podczas gdy zmienna ta została początkowo uznana za niestabilną. Widziałem to w przykładzie klasy singleton, gdzie zadeklarowali unikalną instancję jako zmienną i sychronizowali blok, który inicjuje tę instancję ... Moje pytanie brzmi: dlaczego deklarujemy to jako niestabilne, podczas gdy my je synchronizujemy, dlaczego potrzebujemy obu? czy żaden z nich nie jest wystarczający dla drugiego?

public class someClass { 
volatile static uniqueInstance = null; 

public static someClass getInstance() { 
     if(uniqueInstance == null) { 
      synchronized(someClass.class) { 
       if(uniqueInstance == null) { 
        uniqueInstance = new someClass(); 
       } 
      } 
     } 
     return uniqueInstance; 
    } 

z góry dzięki.

Answer 1

Synchronizacja sama w sobie wystarczyłaby, gdyby pierwsza kontrola była w zsynchronizowanym bloku (ale tak nie jest i jeden wątek może nie widzieć zmian dokonanych przez inny, jeśli zmienna nie była niestabilna). Samotność sama w sobie nie wystarczy, ponieważ trzeba wykonać więcej niż jedną operację atomowo. Ale strzeż się! To, co tu masz, to tak zwane "podwójne sprawdzanie" - wspólny język, który niestety jest następujący: does not work reliably. Myślę, że zmieniło się to od wersji 1.6, ale nadal ten rodzaj kodu może być ryzykowny.

EDIT: gdy zmienna jest lotny, ten kod działa poprawnie, ponieważ JDK 5 (nie 6 jak pisałem wcześniej), ale to nie będzie działać zgodnie z oczekiwaniami pod JDK 1.4 lub starszej.

Answer 2

This post wyjaśnia ideę volatile.

Jest to również adresowane w pracach nadrzędnych, Java Concurrency in Practice.

Główną ideą jest to, że współbieżność obejmuje nie tylko ochronę wspólnego państwa, ale także widoczności tym stanie pomiędzy wątkami: to gdzie lotny przychodzi (Ten większy kontrakt jest określony przez Java Memory Model.)

Answer 3

to. używa podwójnie sprawdzanego blokowania, zauważ, że if(uniqueInstance == null) nie znajduje się w zsynchronizowanej części.

Jeśli uniqueInstance nie jest niestabilny, może zostać "zainicjowany" częściowo utworzonym obiektem, którego części nie są widoczne dla innego niż wątek wykonywany w bloku synchronized. volatile sprawia, że ​​jest to operacja wszystko albo nic w tym przypadku.

Jeśli nie masz zsynchronizowanego bloku, możesz skończyć z dwoma wątkami docierającymi do tego punktu w tym samym czasie.

if(uniqueInstance == null) { 
     uniqueInstance = new someClass(); <---- here 

Tworzysz 2 obiekty SomeClass, które pokonują cel.

Ściśle mówiąc, nie trzeba lotny, metoda mogło

public static someClass getInstance() { 
    synchronized(FullDictionary.class) { 
     if(uniqueInstance == null) { 
      uniqueInstance = new someClass(); 
      } 
     return uniqueInstance; 
    } 
} 

Ale to ponosi synchronizację i szeregowanie każdego wątku, który wykonuje getInstance().

Answer 4

Możesz synchronizować bez blokowania zsynchronizowanego. Nie jest konieczne użycie zmiennej lotnej w niej ... lotne aktualizuje jedną zmienną z pamięci głównej .. i zsynchronizowane Zaktualizuj wszystkie zmienne współdzielone, do których dostęp uzyskano z pamięci głównej. Dzięki czemu można go używać zgodnie z wymaganie..

Answer 5

Moje dwa centy tutaj

Frist szybkie wyjaśnienie intuicji tego kodu

if(uniqueInstance == null) { 
     synchronized(someClass.class) { 
      if(uniqueInstance == null) { 
       uniqueInstance = new someClass(); 
      } 
     } 
    } 

Powodem sprawdza uniqueInstance == null dwukrotnie jest zmniejszenie narzutu wywołanie bloku, który jest zsynchronizowany relatywnie wolniej. Tak zwane podwójne sprawdzanie blokowania.

Po drugie, powód, dla którego jest używany zsynchronizowany, jest łatwy do zrozumienia, czyni dwie operacje wewnątrz zsynchronizowanego bloku atomowego.

Ostatni lotny modyfikator zapewnia, że ​​wszystkie wątki widzą tę samą kopię, więc pierwsze sprawdzenie poza zsynchronizowanym blokiem wyświetli wartość uniqueInstance w sposób "zsynchronizowany" z synchronizowanym blokiem. Bez niestabilnego modyfikatora jeden wątek może przypisać wartość do uniqueInstance, ale drugi wątek może go nie widzieć po pierwszym sprawdzeniu. (Chociaż drugi test go zobaczy)