¿Por qué es volátil utilizado en este ejemplo de una doble comprobación de bloqueo

Question

De Cabeza En primer libro de patrones de diseño, el patrón Singleton con bloqueo doble comprobación se ha implementado de la siguiente manera:

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

no entiendo por qué es ser volatile usado. ¿El uso de volatile no derrota el propósito del uso de doble bloqueo comprobado, es decir, el rendimiento?

Answer 1

Se necesita un buen recurso para comprender por qué se necesita volatile del libro . Wikipedia tiene un decent explanation de ese material también.

El problema real es que Thread A puede asignar un espacio de memoria para instance antes de que termine de construir instance. Thread B verá esa asignación e intentará usarla. Esto da como resultado Thread B que falla porque está utilizando una versión parcialmente construida de instance.

Answer 2

Si no lo tiene, un segundo subproceso podría entrar en el bloque sincronizado después de que el primero lo estableciera en nulo, y su caché local todavía pensaría que era nulo.

El primero no es para ser correcto (si fuera correcto, sería autodestructivo) sino para optimizarlo.

Answer 3

Declarar la variable como volatile garantiza que todos los accesos realmente lean su valor actual de la memoria.

Sin volatile, el compilador puede optimizar los accesos a la memoria y mantener su valor en un registro, por lo que solo el primer uso de la variable lee la ubicación real de la memoria que contiene la variable. Esto es un problema si la variable es modificada por otro hilo entre el primer y el segundo acceso; el primer subproceso solo tiene una copia del primer valor (pre-modificado), por lo que la segunda instrucción if prueba una copia obsoleta del valor de la variable.

Answer 4

Bueno, no hay doble bloqueo verificado para el rendimiento. Es un roto patrón.

emociones Dejando de lado, volatile está aquí porque sin ella por el tiempo pasa instance == null segundo hilo, primer hilo podría no construye new Singleton() aún: nadie se promete que la creación del objeto sucede antes asignación a instance para cualquier hilo, pero el que realmente crea el objeto.

volatile a su vez establece sucede antes de relación entre lecturas y escrituras, y corrige el patrón roto.

Si está buscando rendimiento, utilice la clase estática interna del soporte en su lugar.

Answer 5

Una lectura volátil no es realmente cara en sí misma.

Puede diseñar una prueba para llamar al getInstance() en un ciclo cerrado, para observar el impacto de una lectura volátil; sin embargo, esa prueba no es realista; En tal situación, el programador normalmente llama al getInstance() una vez y almacena en caché la instancia por el tiempo de uso.

Otra impl es mediante el uso de un campo final (ver wikipedia). Esto requiere una lectura adicional, que puede ser más costosa que la versión volatile. La versión final puede ser más rápida en un circuito cerrado, sin embargo, esa prueba es discutible como se argumentó anteriormente.

Answer 6

Según lo citado por @irreputable, volátil no es caro. Incluso si es costoso, la consistencia debe tener prioridad sobre el rendimiento.

Hay una manera más limpia y elegante para Lazy Singletons.

public final class Singleton { 
    private Singleton() {} 
    public static Singleton getInstance() { 
     return LazyHolder.INSTANCE; 
    } 
    private static class LazyHolder { 
     private static final Singleton INSTANCE = new Singleton(); 
    } 
} 

Fuente del artículo: Initialization-on-demand_holder_idiom de Wikipedia

En la ingeniería de software, el titular de inicialización en la demanda (patrón de diseño) modismo es un producto único, cargado ligeramente. En todas las versiones de Java, el lenguaje permite una inicialización perezosa segura, altamente concurrente con buen rendimiento

Puesto que la clase no tiene ningún static variables para inicializar, la inicialización completa trivial.

La definición de clase estática LazyHolder dentro de ella no se inicializa hasta que la JVM determine que se debe ejecutar LazyHolder.

La clase estática LazyHolder sólo se ejecuta cuando el método estático getInstance se invoca en la clase Singleton, y la primera vez que esto sucede la JVM cargar e inicializar la clase LazyHolder.

Esta solución es segura para subprocesos sin requerir construcciones de lenguaje especiales (es decir, volatile o synchronized).