Настав час зняти синхронізовану систему, зачекати та сповістити?

Чи існує єдиний сценарій (окрім сумісності із старовинними JVM), коли використання synchronizedкраще використовувати Lock? Чи може хтось виправдати використання waitчи notifyновіші системи?

Чи є якийсь алгоритм, який повинен використовувати один із них у своїй реалізації?

Я бачу попередні питання, які торкалися цього питання, але я хотів би трохи пізніше поставитись до цього, і власне до deprecateних. Занадто багато пасток і підводних каменів і застережень, які були випрасувані новими спорудами. Я просто відчуваю, що скоро може настати час відзначити їх застарілими.

java synchronization deprecation

— OldCurmudgeon
джерело

Чи читали ви на практиці Брайана Гетца Java Concurrency? Він добре висвітлює неявну та явну дискусію щодо блокування.

— Мартійн Вербург

@MartijnVerburg - На жаль, але я дуже поважаю його роботу.

— OldCurmudgeon

синхронізоване ключове слово може бути корисним за допомогою простих статичних методів, які повинні бути безпечними для потоків, для всього іншого я б використовував одночасно Але це моя думка

— Kemoda

Чи є якийсь алгоритм, який повинен використовувати один із них у своїй реалізації?

Майже точно не. (Дійсно, з теоретичної точки зору, ви повинні бути в змозі моделювати очікування / Notify з допомогою інших java.util.concurrent. . Класи. І синхронізується можуть бути замінені явними операціями блокування ... хоча ви повинні бути обережні , щоб розблокувати в finallyпункти.)

Однак, ймовірно, є алгоритми, де найкраще виконання в Java передбачає пряме використання синхронізованого, з очікуванням та сповіщенням або без нього.

Настав час зняти синхронізовану систему, зачекати та сповістити?

Незалежно від відповіді на попереднє запитання, відповідь, безумовно, немає.

Очікування / сповіщення можна (і часто) використовувати правильно. На Java депресія зарезервована для класів та методів, які порушуються; тобто там, де тривале використання повинно бути негайно виправлено. Якщо Sun (а зараз Oracle) знехтував щось таке основне і настільки широко використовується, як чекати / повідомляти, вони створювали б серйозну проблему сумісності для величезної кількості застарілого коду. Це НЕ цікавить когось.

Якщо ви хочете позбутися синхронізованого / зачекати / повідомити у своєму коді, це добре. Але припинення вимагає переписування великої кількості по суті правильного багатопотокового коду, і це було б BAD IDEA. Корпоративний ІТ-менеджери та менеджери програмних продуктів ненавидять вас за те, що запропонували це ...

Варто ознайомитись з тим, що означає "застаріле" відповідно до документації на Java: http://docs.oracle.com/javase/1.5.0/docs/guide/javadoc/deprecation/deprecation.html

А також зауважте, що ми говоримо про знецінення речей, які є основними для мови Java. Депресія synchronizedмає величезні наслідки.

— Стівен С
джерело

Насправді, наскільки я пам’ятаю, згідно з чудовою книгою «Паралельність Java на практиці», java.util.concurrentутилі класи фактично швидші. За лаштунками ці класи безпосередньо спілкуються з VM, де в синхронізованому режимі встановлюється тупий замок на об'єкті в графіку об'єкта і, таким чином, впливає на глобальну ефективність.

— акун

Пробачте мені @Stephen, якщо я натрапив на думку, що ми насправді видаляємо synchronizedі т.д. ін. Я просто пропоную депресію, яка говорить лише про те, що не використовуйте це для нового коду. Я б не мріяв запропонувати пошкодити випробуваний застарілий код, вимагаючи їх усунення.

— OldCurmudgeon

@OldCurmudgeon - доволі пізня відповідь, але я вважаю, що застаріння занадто екстремальне. 1) Це означає, що функцію можна було видалити. 2) Це означає, що функція порушена, на відміну від просто старомодної. 3) Дуже багато людей із задоволенням пишуть новий код таким чином ... і немає жодних вагомих причин цього не робити. 4) Є інші, менш "в обличчя" способи відмовити це; наприклад, написання правил PMD ...

— Stephen C

@StephenC - Чи є тоді трохи менш драматичні дії, які ми можемо вжити, що врешті-решт призведе до того, що вони не будуть використовуватися або навчатися в коледжі. Їх однозначно слід уникати. Я підозрюю, що правила PMD - хоча це і гарна ідея - не дуже швидко дістаються до вчителів.

— OldCurmudgeon

@StephenC Нітпік: переходячи до документів Java, з якими ви пов’язані, я не думаю, що припинення означає, що застарілий код зламаний. Це одна з причин, але, як кажуть документи, API може бути застарілим, коли він заміщений новим, кращим API (як, запевняє ОП, це стосується паралельності). І низький рівень одночасності, якщо насправді не заохочує погану практику, безумовно, дуже схильний до помилок.

— Андрес Ф.