Пришло время отказаться от синхронизации, ждать и уведомлять?

Есть ли один сценарий (кроме совместимости с древними JVM), где использование synchronizedпредпочтительнее, чем использование Lock? Кто-нибудь может оправдать использование waitили notifyболее новые системы?

Есть ли алгоритм, который должен использовать один из них в своей реализации?

Я вижу предыдущие вопросы, которые касались этого вопроса, но я хотел бы пойти немного дальше и на самом деле deprecateих. Слишком много ловушек, ловушек и предостережений с ними, которые были сглажены новыми средствами. Я просто чувствую, что скоро может быть время отметить их устаревшими.

java synchronization deprecation

— OldCurmudgeon
источник

Вы читали о параллельности Java на практике Брайана Гетца? Там он хорошо освещает неявную и явную блокировку.

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

@MartijnVerburg - К сожалению, нет, но я очень уважаю его работу.

— OldCurmudgeon

Ключевое слово synchronized может быть полезно с простыми статическими методами, которые должны быть потокобезопасными, для всего остального, что я бы использовал одновременным. Но это мое мнение

— Kemoda

Есть ли алгоритм, который должен использовать один из них в своей реализации?

Почти наверняка нет. (Действительно, с теоретической точки зрения, вы должны иметь возможность имитировать ожидание / уведомление, используя другие классы java.util.concurrent ... И синхронизированные могут быть заменены явными операциями блокировки ... хотя вам нужно быть осторожным, чтобы разблокировать в finallyстатьи.)

Однако, вероятно , существуют алгоритмы, в которых наиболее эффективная реализация в Java предполагает прямое использование синхронизированных с ожиданием и уведомлением или без него.

Пришло время отказаться от синхронизации, ждать и уведомлять?

Независимо от ответа на предыдущий вопрос, ответ определенно нет.

Ожидание / уведомление могут быть (и часто используются) правильно. В Java устаревание зарезервировано для классов и методов, которые не работают; то есть, где дальнейшее использование должно быть исправлено в срочном порядке. Если бы Sun (а теперь и Oracle) отказались от чего-то столь же фундаментального и столь же широко используемого как ожидание / уведомление, это создало бы серьезную проблему совместимости для огромного количества унаследованного кода. Это НЕ в чьих-либо интересах.

Если вы хотите избавиться от синхронизации / ожидания / уведомления в вашем коде, это нормально. Но устаревание требует переписывания большого количества по существу правильного многопоточного кода, и это будет ПЛОХАЯ ИДЕЯ. Корпоративные ИТ-менеджеры и менеджеры по программным продуктам не хотели бы, чтобы вы предлагали это ...

Стоит прочитать, что означает «устарел» в соответствии с документацией Java: http://docs.oracle.com/javase/1.5.0/docs/guide/javadoc/deprecation/deprecation.html.

Также обратите внимание, что мы говорим об устаревших вещах, которые являются ядром языка Java. Обесценивание synchronizedимеет огромные последствия.

— Стивен С
источник

На самом деле, насколько я помню, согласно превосходной книге «Параллелизм Java на практике», java.util.concurrentклассы util на самом деле быстрее. За кулисами эти классы напрямую общаются с ВМ, где при синхронизации устанавливает тупую блокировку объекта в графе объектов и, таким образом, влияет на глобальную производительность.

— Акун

Прости меня @Stephen, если я натолкнулся на предложение, что мы действительно удалим synchronizedet. и др. Я просто предлагаю устаревший, который на самом деле только говорит, что не используйте это для нового кода. Я бы не мечтал о том, чтобы предложить испортить испытанный и унаследованный код, требуя их удаления.

— OldCurmudgeon

@OldCurmudgeon - довольно поздний ответ, но я думаю, что амортизация слишком экстремальная. 1) Это означает, что функция может быть удалена. 2) Это подразумевает, что функция нарушена, в отличие от простой старомодности. 3) Многие люди все еще рады писать новый код таким образом ... и нет веской причины, по которой они не должны этого делать. 4) Есть другие, менее "в вашем лице" способы препятствовать этому; например, написание правил PMD ...

— Стивен C

@StephenC - Есть ли немного менее драматические действия, которые мы можем предпринять, которые в конечном итоге приведут к тому, что их не будут использовать или преподавать в колледже. Их явно следует избегать. Я подозреваю, что правила PMD - хотя и хорошая идея - не очень быстро дойдут до преподавателей.

— OldCurmudgeon

@StephenC Ненависть: следуя Java-документам, на которые вы ссылаетесь, я не думаю, что устаревание означает, что устаревший код не работает. Это одна из причин, но, как говорится в документации, API может быть признан устаревшим, если он заменен более новым, более совершенным API (как, как утверждает OP, в случае параллелизма). И параллелизм низкого уровня, если не поощряет плохие практики, безусловно, очень подвержен ошибкам.

— Андрес Ф.