¿Cuál es la diferencia entre sincronizado en lockObject y usando esto como el bloqueo?

Question

Conozco la diferencia entre el método sincronizado y el bloque sincronizado, pero no estoy seguro acerca de la parte sincronizada del bloque.

Suponiendo que tengo este código

class Test { 
    private int x=0; 
    private Object lockObject = new Object(); 

    public void incBlock() { 
    synchronized(lockObject) { 
     x++; 
    } 
    System.out.println("x="+x); 
    } 

    public void incThis() { // same as synchronized method 
    synchronized(this) { 
     x++; 
    } 
    System.out.println("x="+x); 
    } 
} 

En este caso, ¿cuál es la diferencia entre usar cuadro LockObject y el uso de este como la cerradura? Parece ser lo mismo para mí ...

Cuando decide utilizar el bloque sincronizado, ¿cómo decide qué objeto será el bloqueo?

Answer 1

Personalmente, casi nunca me fijo en "esto". Normalmente me fijo en una referencia privada que sé que ningún otro código va a bloquear. Si bloquea "this" entonces cualquier otro código que conozca su objeto puede elegir bloquearlo. Si bien es poco probable que suceda, sin duda podría hacerlo, y podría causar bloqueos o un bloqueo excesivo.

No hay nada particularmente mágico en lo que encierras, puedes pensarlo como una ficha, efectivamente. Cualquiera que trabaje con la misma ficha intentará adquirir el mismo bloqueo. A menos que desee otro código para poder adquirir el mismo candado, use una variable privada. Me gustaría también le animo a hacer la variable final - No puedo recordar una situación en la que alguna vez quería cambiar una variable de bloqueo durante la vida útil de un objeto.

Answer 2

En este caso, no importa qué objeto elija para el bloqueo. Pero debe usar consistentemente el mismo objeto para bloquear para lograr la sincronización correcta. El código anterior no garantiza la sincronización adecuada ya que una vez usa el objeto 'this' como candado y luego el 'lockObject' como candado.

Answer 3

El artículo 67 de Effective Java Second Edition es Evitar la sincronización excesiva, por lo tanto, me sincronizaría en un objeto de bloqueo privado.

Answer 4

Cada objeto en Java puede actuar como un monitor. Elegir uno depende de la granularidad que desee. Elegir 'esto' tiene la ventaja y la desventaja de que otras clases también podrían sincronizarse en el mismo monitor. Sin embargo, mi consejo es evitar el uso directo de la palabra clave synchronize y, en su lugar, usar constructos de la biblioteca java.util.concurrency, que son de nivel superior y tienen una semántica bien definida. Este libro tiene un montón de buenos consejos en él de los expertos muy notables:

Java concurrencia en la práctica http://amzn.com/0321349601

Answer 5

tuve esta misma pregunta cuando estaba leyendo Java concurrencia en la práctica, y pensé que me gustaría añadir una perspectiva adicional sobre las respuestas proporcionadas por Jon Skeet y spullara.

Aquí hay un código de ejemplo que bloqueará incluso los métodos "rápidos" setValue(int)/getValue() mientras se ejecuta el método doStuff(ValueHolder).

public class ValueHolder { 
    private int value = 0; 

    public synchronized void setValue(int v) { 
     // Or could use a sychronized(this) block... 
     this.value = 0; 
    } 

    public synchronized int getValue() { 
     return this.value; 
    } 
} 

public class MaliciousClass { 

    public void doStuff(ValueHolder holder) { 
     synchronized(holder) { 
      // Do something "expensive" so setter/getter calls are blocked 
     } 
    } 
} 

La desventaja de usar this para la sincronización es otras clases pueden sincronizar en una referencia a su clase (no a través this, por supuesto).El uso malintencionado o no intencionado de la palabra clave synchronized al bloquear la referencia de su objeto puede hacer que su clase se comporte mal con el uso simultáneo, ya que una clase externa puede bloquear eficazmente sus this métodos sincronizados y no hay nada que pueda hacer (en su clase) para prohibir esto en tiempo de ejecución. Para evitar este peligro potencial, se sincronizaría en un private final Object o utilizaría la interfaz Lock en java.util.concurrent.locks.

Para este ejemplo simple, puede usar alternativamente un AtomicInteger en lugar de sincronizar el setter/getter.