Dlaczego wait() i notify() nie należą do specjalnej klasy?

Question

Dlaczego metody są umieszczane w , a nie w oddzielnej klasie?

Uwaga, to pytanie nie dotyczy przeniesienia ich do klasy Thread, po prostu zastanawiam się, dlaczego nie zawierają one Object, a nie jakiejś nowej klasy Monitor.

widzę następujące wady tego pomysłu:

• My nie będą mogli korzystać z naszych for-innego przeznaczenia pola jako monitory. Ale wydaje się to zgadzać z zasadą modułowości.
• Metody zsynchronizowane będą teraz wymagać hakowania z wygenerowanymi ukrytymi polami (jak w zamknięciach), ponieważ this i <MyClass>.class stają się niepoprawnymi monitorami.

Dzięki temu możemy odejść 5 metod z każdego obiektu z lekkim niedolem. Albo nie?

Answer 1

Prawdziwą odpowiedzią jest, że był to błąd, ostatecznie potwierdzony przez stworzenie klasy Condition, która robi dokładnie to, czego można się spodziewać. (Chociaż ponieważ jest to przedmiot, istnieje możliwość, że będziesz przypadkowo wywołać wait() na nim zamiast await() z zabawnych konsekwencji ...)

Oprócz rzeczy, które zostały już wymienione, wiążąc monitor do każdego pojedynczego obiektu uniemożliwia również posiadanie prawdziwie niezmiennych obiektów w Javie.

Więc można to zrobić na przykład:

class A { 
    void foo() { 
     synchronized((Integer)42) { 
     ... 
     } 
    } 
} 

class B { 
    void foo() { 
     synchronized((Integer)42) { 
      ... 
     } 
    } 
} 

Wracając tą samą całkowitą pudełkowej dla 42 za każdym razem nie powinno być problemem, jeśli obiekt był niezmienny. Ale nie jest, ma zmienny stan: swój monitor, umożliwiający taką synchronizację. Szczególnie złym jest to, że stworzyłeś muteks między dwoma fragmentami kodu, które na pierwszy rzut oka wydają się niezależne.

Answer 2

Ponieważ każdy obiekt może działać jako monitor.

Answer 3

1) Oczekiwanie na powiadomienie i powiadomienie to nie tylko zwykłe metody lub narzędzie do synchronizacji, ale więcej niż mechanizm komunikacji między dwoma wątkami w Javie. Klasa obiektu jest właściwym miejscem do udostępnienia dla każdego obiektu, jeśli ten mechanizm nie jest dostępny za pośrednictwem dowolnego słowa kluczowego Java, takiego jak synchronizacja. Pamiętaj, że zsynchronizowane i oczekujące powiadomienia są dwoma różnymi obszarami i nie mylić, że są takie same lub powiązane. Synchronizacja ma zapewniać wzajemne wykluczanie i zapewniać bezpieczeństwo wątków klasy Java, takich jak warunki wyścigu, podczas gdy oczekiwanie i powiadamianie to mechanizm komunikacji między dwoma wątkami.

2) Blokady są udostępniane dla każdego obiektu, co jest kolejnym powodem oczekiwania i powiadomienia w klasie Obiekt, a nie w klasie Wątków.

3) W Javie, aby wejść do krytycznej sekcji kodu, wątki wymagają zablokowania i czekają na blokadę, nie wiedzą, które wątki blokują, zamiast tego po prostu wiedzą, że blokada jest zatrzymana przez jakiś wątek i powinny poczekać dla blokady zamiast wiedzieć, który wątek znajduje się wewnątrz zsynchronizowanego bloku i poprosić go o zwolnienie blokady. ta analogia pasuje do czekania i powiadamiania o klasie obiektu, a nie wątku w Javie.

z dopiskiem: http://javarevisited.blogspot.in/2012/02/why-wait-notify-and-notifyall-is.html

Answer 4

Jedną z zalet jest to, że można po prostu zsynchronizować na odniesienie bez tworzenia redundantnego monitora do niego:

synchronized (myList) { 
    myList.add(0); 
} 

vs

private final Object mySpecialMonitor = new Object(); 

syncronized(mySpecialMonitor) { 
    myList.add(0); 
} 

Byłoby nie działa, jeśli cała synchronizacja była w osobnej klasie.