patrón singleton en java. inicialización diferida

Question

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

1.¿Hay algún problema con la implementación anterior del método getInstance? 2. ¿Cuál es la diferencia entre las dos implementaciones?

public static synchronized MySingleton getInstance() { 
if (_instance==null) { 
    _instance = new MySingleton(); 
} 

return _instance; 
} 

He visto una gran cantidad de respuestas en el patrón singleton en stackoverflow pero la pregunta que he publicado es conocer principalmente la diferencia de 'sincronizar' en el método y nivel de bloque en este caso particular.

Answer 1

1.¿Hay algún problema con la implementación anterior del método getInstance ?

No funciona. Puede terminar con varias instancias de su Singleton.

2.¿Cuál es la diferencia entre las dos implementaciones?

El segundo funciona, pero requiere sincronización, lo que podría ralentizar el sistema cuando tiene muchos accesos al método desde diferentes subprocesos.

La correcta implementación más sencilla:

public class MySingleton{ 
    private static final MySingleton _instance = new MySingleton(); 
    private MySingleton(){} 
    public static MySingleton getInstance() { 
     return _instance; 
    } 
} 

más corto y mejor (con seguridad serializable):

public enum MySingleton{ 
    INSTANCE; 

    // methods go here 
} 

inicialización perezosa de hijos únicos es un tema que llama la atención manera fuera de proporción con su la utilidad práctica real (la OMI argumentando sobre las complejidades del bloqueo con doble verificación, para lo cual su ejemplo es el primer paso, no es más que un concurso de meadas).

En el 99% de los casos, no necesita ninguna inicialización diferida, o el "init cuando la clase se refiere por primera vez" de Java es lo suficientemente bueno. En el 1% restante de los casos, esta es la mejor solución:

public enum MySingleton{ 
    private MySingleton(){} 
    private static class Holder { 
     static final MySingleton instance = new MySingleton(); 
    } 
    static MySingleton getInstance() { return Holder.instance; } 
} 

Answer 2

1.¿Hay algún problema con la implementación anterior del método getInstance ?

Sí, la palabra clave sincronizada también debe incluir la instrucción if. Si no es así, dos o más hilos podrían llegar al código de creación.

2.¿Cuál es la diferencia entre las dos implementaciones?

La segunda implementación es correcta y, desde mi punto de vista, más fácil de entender.

El uso de sincronizado en el nivel de método para un método estático se sincroniza en la clase, es decir, lo que ha hecho en la muestra 1. El uso sincronizado en el nivel de método para un método de instancia se sincroniza en la instancia del objeto.

Answer 3

El segundo es hilo de seguridad, pero tiene la sobrecarga de sincronizada en cada llamada, no importa si la instancia se construye o no.La primera opción tiene un error importante que no tiene una comprobación para if (_instance == null) en el bloque sincronizado para evitar la creación de dos instancias.

Answer 4

La primera es defectuosa de dos maneras. Como otros han mencionado aquí, varios subprocesos pueden obtener a través de

if (_instance==null) { 

que esperarían unos a otros, hasta que el objeto está completamente construido, pero que harían la creación de instancias y sustituir la referencia en la variable.

El segundo defecto es un poco más complicado. Un hilo podría entrar en el constructor new MySingleton() y luego la JVM cambia a otro hilo. Otro hilo puede verificar la variable para null, pero puede contener una referencia a un objeto parcialmente construido. Entonces, el otro hilo funciona en Singleton parcialmente construido, eso tampoco es bueno. Por lo tanto, debe evitarse la primera variante.

La segunda variante debería funcionar bien. No le importa demasiado la eficiencia, hasta que identifique esto claramente como bloqueador. Las JVM modernas pueden optimizar las sincronizaciones innecesarias, por lo que en el código de producción real esta construcción nunca puede perjudicar el rendimiento.

Answer 5

Los diversos enfoques para singletons perezoso de carga son discutidos por Bob Lee en Lazy Loading Singletons y el enfoque de "derecho" es la Initialization on Demand Holder (IODH) idiom que requiere muy poco código y tiene gastos generales de sincronización cero.

static class SingletonHolder { 
    static Singleton instance = new Singleton();  
} 

public static Singleton getInstance() { 
    return SingletonHolder.instance; 
} 

Bob Lee también explica cuándo quiere cargar un singleton (durante las pruebas y el desarrollo). Honestamente, no estoy convencido de que haya un gran beneficio.

Answer 6

que sugeriría la siguiente implementación

public class MySingleTon 
{ 

    private static MySingleton obj; 

    //private Constructor 
    private MySingleTon() 
    { 
    } 


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