Czy nadszedł czas, aby przestać synchronizować, czekać i powiadamiać?

Czy istnieje jeden scenariusz (inny niż zgodność ze starożytnymi maszynami JVM), w którym użycie synchronizedjest lepsze niż użycie Lock? Czy ktoś może uzasadnić używanie nowszych systemów waitlub korzystanie notifyz nich?

Czy istnieje algorytm, który musi wykorzystywać jeden z nich w swojej implementacji?

Widzę poprzednie pytania, które dotyczyły tej kwestii, ale chciałbym pójść o krok dalej i to właściwie deprecate. Jest o wiele za dużo pułapek, pułapek i zastrzeżeń, które zostały rozwiązane dzięki nowym obiektom. Po prostu czuję, że wkrótce nadszedł czas, aby oznaczyć je jako przestarzałe.

java synchronization deprecation

— OldCurmudgeon
źródło

Czy czytałeś w praktyce współbieżność Java Briana Goetza w praktyce? Ładnie omawia ukrytą debatę kontra jawna blokada.

— Martijn Verburg

@MartijnVerburg - Niestety nie, ale mam ogromny szacunek dla jego pracy.

— OldCurmudgeon

Zsynchronizowane słowo kluczowe może być przydatne z prostymi metodami statycznymi, które powinny być bezpieczne dla wątków, do wszystkiego innego, czego użyłbym jednocześnie. Ale to moja opinia

— Kemoda

Czy istnieje algorytm, który musi wykorzystywać jeden z nich w swojej implementacji?

Prawie na pewno nie. (Rzeczywiście, z perspektywy teoretycznej, powinieneś być w stanie symulować wait / notify pomocą innego java.util.concurrent. . Klas. I zsynchronizowane można zastąpić wyraźnych działań zamków ... choć trzeba by uważać, aby odblokować w finallyklauzule).

Jednakże, istnieje prawdopodobnie algorytmy gdzie najlepiej wykonując implementacja w Javie polega na bezpośrednie wykorzystanie zsynchronizowane, z lub bez czekać i powiadomić.

Czy nadszedł czas, aby przestać synchronizować, czekać i powiadamiać?

Niezależnie od odpowiedzi na poprzednie pytanie, odpowiedź jest zdecydowanie przecząca.

Funkcja oczekiwania / powiadomienia może być (i często jest) używana poprawnie. W Javie wycofanie jest zarezerwowane dla uszkodzonych klas i metod; tzn. gdy dalsze stosowanie powinno zostać skorygowane w trybie pilnym. Gdyby Sun (a teraz Oracle) wycofał coś tak fundamentalnego i tak powszechnego, jak czekanie / powiadamianie, tworzyłby poważny problem ze zgodnością dla dużej ilości starszego kodu. To NIE jest w niczyim interesie.

Jeśli chcesz pozbyć się zsynchronizowanego / czekaj / powiadom w swoim kodzie, to jest w porządku. Ale wycofanie wymaga przepisania dużej ilości zasadniczo poprawnego kodu wielowątkowego, a to byłby ZŁY POMYSŁ. Menedżerowie IT firmy i menedżerowie oprogramowania nienawidzą cię za sugerowanie tego ...

Warto przeczytać, co oznacza „przestarzałe” zgodnie z dokumentacją Java: http://docs.oracle.com/javase/1.5.0/docs/guide/javadoc/deprecation/deprecation.html

Zauważ też, że mówimy o wycofywaniu rzeczy, które są rdzeniem języka Java. Przestarzałe synchronizedma ogromne konsekwencje.

— Stephen C.
źródło

Właściwie, o ile pamiętam, według doskonałej książki „Współbieżność Java w praktyce”, java.util.concurrentklasy util są w rzeczywistości szybsze. Za kulisami klasy te bezpośrednio komunikują się z maszyną wirtualną, gdzie podczas synchronizacji instaluje tępą blokadę obiektu na wykresie obiektowym, a tym samym wpływa na globalną wydajność.

— akuhn

Wybacz mi @Stephen, jeśli natknąłem się na sugestię, że faktycznie usunęliśmy synchronizedet. glin. Po prostu sugeruję wycofanie, co tak naprawdę mówi tylko, że nie używaj tego do nowego kodu. Nie marzę o tym, by sugerować uszkodzenie wypróbowanego i przetestowanego starszego kodu, domagając się ich usunięcia.

— OldCurmudgeon

@OldCurmudgeon - raczej późna odpowiedź, ale myślę, że deprecjacja jest zbyt ekstremalna. 1) Oznacza to, że funkcję można usunąć. 2) Oznacza to, że cecha jest zepsuta, w odróżnieniu od zwykłego zachowania. 3) Wiele osób wciąż chętnie pisze w ten sposób nowy kod ... i nie ma żadnego silnego powodu, aby tego nie robić. 4) Istnieją inne, mniej „na twarz” sposoby, aby go zniechęcić; np. pisanie reguł PMD ...

— Stephen C

@StephenC - Czy możemy podjąć nieco mniej dramatyczne działania, które ostatecznie spowodują, że nie będą one używane ani nauczane na studiach. Oczywiście należy ich unikać. Podejrzewam, że zasady PMD - choć dobry pomysł - nie dotrą bardzo szybko do nauczycieli.

— OldCurmudgeon

@StephenC A nitpick: przechodząc przez dokumenty Java, z którymi się łączysz, nie sądzę, że wycofanie oznacza, że przestarzały kod jest uszkodzony. To jeden z powodów, ale jak mówią dokumenty, interfejs API może być przestarzały, gdy zostanie zastąpiony przez nowszy, lepszy interfejs API (jak argumentuje OP, w przypadku współbieżności). A współbieżność niskiego poziomu, jeśli nie zachęca do złych praktyk, z pewnością jest bardzo podatna na błędy.

— Andres F.,