Bloquear en un objeto mutable: ¿por qué se considera una mala práctica?

Question

Consulte esto answer. Dice:

Seis malos ejemplos;

...

de bloqueo en un campo mutable. p.ej. sincronizado (objeto) {objeto = ...; }

¿Qué hay de malo con el bloqueo en un campo mutable? ¿Qué pasa si object se declaró como final pero no era una clase inmutable?

Answer 1

No es una buena idea porque si otro hilo cambia la referencia en la sección crítica, los hilos ya no verán la misma referencia, por lo que no se sincronizarán en el mismo objeto, por lo tanto se ejecutarán sin control. Ejemplo:

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

Supongamos que hay 2 hilos intentando ingresar a esta sección crítica. El hilo 1 entra y el hilo 2 espera. El hilo 1 entra, reasigna lock1 y procede. Ahora el hilo 2 ve un bloqueo diferente de lo que el hilo 1 adquirió, que también es libre, por lo que también puede ingresar a la sección crítica. ¡La diversión sigue!

Si el objeto es final, no puede reasignar la referencia a un objeto diferente, por lo que el problema anterior ya no se aplica.

Answer 2

"Mutable" no es la palabra adecuada aquí. Está bien bloquear un objeto mutable, es decir, un objeto con estado. Lo que está mal es bloquear un campo, cambiarlo y esperar que otro hilo se bloquee en el mismo objeto.

Answer 3

No creo que bloquear un objeto mutable sea malo en sí mismo. Es muy difícil hacerlo bien. Hay otros modelos para procesamiento concurrente, como actores. Sugiero que busque en Akka, que se puede usar tanto en Java como en Scala, y es una implementación muy sólida.