¿Puedo usar sincronizado con un campo final?

Question

Considerar siguiente código, quiero que sea una clase de seguro de rosca, de modo que nunca conseguirá número impar:

class Test { 
    private int value = 0; 
    private final Object lock; 

    public void add() { 
    synchronized (lock) { 
     value++; 
     value++; 
    } 
    } 

    public int getValue() { 
    synchronized (lock) { 
     return value; 
    } 
    } 
} 

Ahora estoy duda del campo de bloqueo, que se declara a ser definitiva, ¿esto ¿importar? o romperá la seguridad del hilo?

Creo que si el campo de bloqueo no se declara como final, esta debería ser una clase segura para subprocesos. Si esta conclusión es incorrecta, por favor corrígeme, gracias.

Answer 1

Ahora tengo dudas sobre el campo de bloqueo, que se declara definitivo, ¿será esto importante?

Sí, es considerada la mejor práctica a única bloquear final objetos de campo.

Si puede cambiar la referencia, puede cambiar qué objeto está bloqueado, rompiendo la seguridad del hilo.

Answer 2

En Java, la sincronización se realiza mediante un campo oculto del objeto de bloqueo. También significa que la REFERENCIA es definitiva, no el objeto en sí mismo.

Ejemplo:

final Bar bar = new Bar(); //bar hase property lock 
bar.lock = XYZ; //will work, object is not FINAL 
bar = new Bar(); //fail, the reference is FINAL 

Answer 3

debe estar bien. incluso podría hacerlo más seguro, ya que uno no puede simplemente asignar algo más al bloqueo durante la ejecución.

Answer 4

Puede usar el ReadWriteLock para lograr el mismo resultado y con una implementación segura.

Referencias:

http://docs.oracle.com/javase/1.5.0/docs/api/java/util/concurrent/locks/ReadWriteLock.html

http://www.javapractices.com/topic/TopicAction.do?Id=118

Answer 5

Si usted está buscando para bloquear un ejemplo, entonces final es aceptable. Si busca bloquear o poner un mutex en una clase, establezca la variable estática.

Answer 6

Cuando intenta sincronizar varios hilos, deben estar sincronizados en función de la misma referencia/instancia del objeto. Esto garantiza que ambos se sincronicen al mismo tiempo en función de los mismos datos.

Espero que tenga un poco de sentido; solo tiene que sincronizar en función de una variable finalizada en lugar de una dinámica.

Si un método modifica un campo estático, debe sincronizar el acceso a este campo, incluso si el método se utiliza normalmente por un solo hilo. No es posible que los clientes realicen una sincronización externa en tal método porque no puede haber ninguna garantía que los clientes no relacionados hagan lo mismo, see.