¿La palabra clave Java sincronizada vacía el caché?

Question

Java 5 y superior solamente. Supongamos una computadora de memoria compartida multiprocesador (probablemente esté usando una en este momento).

Aquí es un código de inicialización perezosa de un producto único:

public final class MySingleton { 
    private static MySingleton instance = null; 
    private MySingleton() { } 
    public static MySingleton getInstance() { 
    if (instance == null) { 
     synchronized (MySingleton.class) { 
     if (instance == null) { 
      instance = new MySingleton(); 
     } 
     } 
    } 
    return instance; 
    } 
} 

¿Tiene instance tienen que ser declarado volatile con el fin de impedir que el optimizador de reescritura getInstance() de la siguiente manera (lo que sería correcto en un secuencial programa):

public static MySingleton getInstance() { 
    if (instance == null) { 
    synchronized (MySingleton.class) { 
     // instance must be null or we wouldn't be here (WRONG!) 
     instance = new MySingleton(); 
    } 
    } 
} 

Suponiendo que el optimizador no volver a escribir el código, si no se ha declarado instancevolatile está todavía garantizada para ser enviado a la memoria cuando se sale del bloque synchronized y se lee desde la memoria cuando se ingresa el bloque synchronized?

EDITAR: Olvidé hacer que getInstance() static. No creo que eso cambie la validez de las respuestas; todos sabían lo que quería decir.

Answer 1

Sí, instance debe declararse volatile. Incluso entonces, se aconseja no usar el bloqueo con doble verificación. (O para ser precisos, el modelo de memoria de Java) solía tener un defecto grave que permitía la publicación de objetos parcialmente implementados. Esto se ha solucionado en Java5, todavía DCL es una expresión idiomática obsoleta y ya no es necesario usarla. En su lugar, use lazy initialization holder idiom.

De Java Concurrency in Practice, sección 16.2:

El verdadero problema con DCL es el supuesto de que lo peor que puede suceder cuando se lee una referencia de objeto compartido sin sincronización es ver erróneamente un valor rancio (en este caso , null); en ese caso, la expresión DCL compensa este riesgo al intentar nuevamente con la cerradura retenida. Pero el peor de los casos es considerablemente peor: es posible ver un valor actual de la referencia pero valores obsoletos para el estado del objeto, lo que significa que podría verse que el objeto está en un estado no válido o incorrecto.

Los cambios posteriores en la JMM (Java 5.0 y posterior) han permitido DCL a trabajar si resource se hace volatile, y el impacto en el rendimiento de esto es pequeña, ya que volatile lecturas son por lo general sólo un poco más caro que lee no volátil. Sin embargo, este es un modismo cuya utilidad ha pasado en gran medida: las fuerzas que lo motivaron (sincronización lenta sin control, arranque lento de JVM) ya no están en juego, lo que lo hace menos efectivo como optimización. La expresión idiomática del titular de inicialización perezosa ofrece los mismos beneficios y es más fácil de entender.

Answer 2

Ver http://www.javaworld.com/jw-02-2001/jw-0209-double.html

Answer 3

Sí, ejemplo tiene que ser volátil utilizando una doble comprobación de bloqueo en Java, porque de lo contrario la inicialización de MySingleton podría exponer un objeto construido parcialmente con el resto del sistema. También es cierto que los hilos se sincronizarán cuando lleguen a la declaración "sincronizada", pero eso es demasiado tarde en este caso.

Wikipedia y un par de otras preguntas de desbordamiento de pila tienen buenas discusiones de "bloqueo comprobado doble", por lo que le aconsejo que lea sobre ello. También aconsejo no usarlo a menos que los perfiles muestren una necesidad real de rendimiento en este código en particular.

Answer 4

Hay un lenguaje más seguro y más fácil de leer para la inicialización perezosa de embarazos únicos Java:

class Singleton { 

    private static class Holder { 
    static final Singleton instance = create(); 
    } 

    static Singleton getInstance() { 
    return Holder.instance; 
    } 

    private Singleton create() { 
    ⋮ 
    } 

    private Singleton() { } 

} 

Si se utiliza el patrón de una doble comprobación más exhaustiva de bloqueo, hay que declarar el campo volatile, como otros tienen ya anotado

Answer 5

No. No tiene que ser volátil. Ver How to solve the "Double-Checked Locking is Broken" Declaration in Java?

intentos anteriores, todos fallaron porque si puedes engañar a Java y evitar volátil/sincronización, Java puede engañarte y darte una vista incorrecta del objeto. sin embargo, la nueva semántica final resuelve el problema. si obtiene una referencia de objeto (por lectura ordinaria), puede leer con seguridad sus campos final.