¿por qué usar volátiles con bloque sincronizado?

Question

vi algunos ejemplos en java donde realizan la sincronización en un bloque de código para cambiar alguna variable, mientras que la variable se declaró originalmente volátil .. Vi que en un ejemplo de la clase Singleton, donde declararon la instancia única como volátil y que Sychronized el bloque que inicializa esa instancia ... Mi pregunta es por qué lo declaramos volátil mientras nos sincronizamos, ¿por qué tenemos que hacer ambas cosas? no es uno de ellos es suficiente para el otro?

public class someClass { 
volatile static uniqueInstance = null; 

public static someClass getInstance() { 
     if(uniqueInstance == null) { 
      synchronized(someClass.class) { 
       if(uniqueInstance == null) { 
        uniqueInstance = new someClass(); 
       } 
      } 
     } 
     return uniqueInstance; 
    } 

gracias de antemano.

Answer 1

sincronización por sí mismo sería suficiente en este caso si la primera verificación estaba dentro de bloque sincronizado (pero no es y un hilo podría no ver los cambios realizados por otro si la variable no eran volátil). Solo volátil no sería suficiente porque necesita realizar más de una operación atómicamente. ¡Pero cuidado! Lo que tenemos aquí es llamado bloqueo doble comprobación - un lenguaje común, que por desgracia does not work reliably. Creo que esto ha cambiado desde Java 1.6, pero aún este tipo de código puede ser riesgoso.

EDIT: cuando la variable es volátil, este código funciona correctamente desde JDK 5 (no 6 como escribí anteriormente), pero no funcionará como se esperaba bajo JDK 1.4 o anterior.

Answer 2

This post explica la idea detrás volátil.

También se aborda en el trabajo seminal, Java Concurrency in Practice.

La idea principal es que la concurrencia no sólo implica la protección del estado compartido, sino también la visibilidad de ese estado entre los hilos: Aquí es donde entra volátil en (Este contrato más grande se define por la Java Memory Model.)

Answer 3

Este. utiliza el bloqueo comprobado doble, tenga en cuenta que el if(uniqueInstance == null) no se encuentra dentro de la parte sincronizada.

Si uniqueInstance no es volátil, podría "inicializarse" con un objeto parcialmente construido donde partes de él no son visibles a menos que la ejecución de subproceso en el bloque synchronized. volátil hace de esto una operación de todo o nada en este caso.

Si no tiene el bloque sincronizado, puede terminar con 2 hilos llegando a este punto al mismo tiempo.

if(uniqueInstance == null) { 
     uniqueInstance = new someClass(); <---- here 

Y construye 2 objetos SomeClass, lo que infringe el propósito.

En sentido estricto, no es necesario volátiles, el método podría haber sido

public static someClass getInstance() { 
    synchronized(FullDictionary.class) { 
     if(uniqueInstance == null) { 
      uniqueInstance = new someClass(); 
      } 
     return uniqueInstance; 
    } 
} 

Pero que incurre la sincronización y la serialización de cada hilo que realiza getInstance().

Answer 4

Puede sincronizar sin utilizar el bloque sincronizado. No es necesario el uso de una variable de volátiles en ella ... actualizaciones volátiles de la una variable de memory..and principal actualización sincronizada todas las variables compartidas que se ha accedido desde la memoria principal .. Por lo tanto se puede usar de acuerdo a su requisito..

Answer 5

Mis dos centavos aquí

Frist una explicación rápida de la intuición de este código

if(uniqueInstance == null) { 
     synchronized(someClass.class) { 
      if(uniqueInstance == null) { 
       uniqueInstance = new someClass(); 
      } 
     } 
    } 

La razón comprueba uniqueInstance == null dos veces es reducir la sobrecarga de llamar el bloque sincronizado que es relativamente más lento. El llamado bloqueo con doble verificación.

En segundo lugar, la razón por la que utiliza sincronización es fácil de entender, hace que las dos operaciones dentro del bloque sincronizado sean atómicas.

Por último, el modificador volátil asegura que todos los hilos vean la misma copia, de modo que la primera comprobación fuera del bloque sincronizado verá el valor de la instancia única de forma "sincronizada" con el bloque sincronizado. Sin el modificador volátil, un subproceso puede asignar un valor a uniqueInstance pero el otro subproceso puede no verlo en la primera comprobación. (Aunque la segunda verificación lo verá)