Блокировка изменяемого объекта - Почему это считается плохой практикой?

Question

См. ответ . Там написано:

Шесть действительно плохих примеров;

...

блокировка изменяемого поля. например синхронизированный (объект) {объект = ...; } * +1010 *

Что не так с блокировкой изменяемого поля? Что если object был объявлен как final, но не был неизменным классом?

Answer 1

Это плохая идея, потому что, если другой поток изменяет ссылку в критическом разделе, потоки больше не будут видеть ту же ссылку, и поэтому они не будут синхронизироваться на одном и том же объекте, таким образом, работая неуправляемо. Пример:

 synchronized(lock1) {
     lock1 = new Object();
     sharedVariable++;
 }

Предположим, 2 потока пытаются войти в этот критический раздел. Входит поток 1, а поток 2 ждет. Поток 1 входит, переназначает lock1 и продолжается. Теперь поток 2 видит блокировку, отличную от той, которую получил поток 1, которая также свободна, поэтому он также может войти в критическую секцию. Веселье наступает!

Если объект final, вы не можете переназначить ссылку на другой объект, поэтому описанная выше проблема больше не применяется.

Answer 2

«Изменчивый» здесь не то слово. Можно заблокировать изменяемый объект, т.е. объект с состоянием. Неправильно заблокировать поле, изменить его и ожидать, что другой поток заблокирует тот же объект.

Answer 3

Я не думаю, что блокирование изменяемого объекта само по себе плохо. Просто очень трудно понять это правильно. Существуют и другие модели параллельной обработки, например, актеры. Я предлагаю вам взглянуть на Akka, который можно использовать как на Java, так и на Scala, и это очень надежная реализация.