Schema singleton con combinazione di caricamento lazy e sicurezza thread

Question

Stavo facendo qualche ricerca sui singleton, in particolare per quanto riguarda l'inizializzazione pigro vs bisognosa di singleton.

Un esempio di inizializzazione ansioso:

public class Singleton 
{ 
    //initialzed during class loading 
    private static final Singleton INSTANCE = new Singleton(); 

    //to prevent creating another instance of Singleton 
    private Singleton(){} 

    public static Singleton getSingleton(){ 
     return INSTANCE; 
    } 
} 

ma come mostrato sopra che è pronto inizializzazione e sicurezza filo viene lasciata JVM ma ora, voglio avere questo stesso modello ma con inizializzazione ritardata.

quindi venire con questo approccio:

public final class Foo { 
    private static class FooLoader { 
     private static final Foo INSTANCE = new Foo(); 
    } 
    private Foo() { 
     if (FooLoader.INSTANCE != null) { 
      throw new IllegalStateException("Already instantiated"); 
     } 
    } 
    public static Foo getInstance() { 
     return FooLoader.INSTANCE; 
    } 
} 

Come mostrato sopra Poiché la linea

private static final Foo INSTANCE = new Foo(); 

viene eseguita solo quando il FooLoader classe viene effettivamente utilizzato, questo prende cura della istanziazione pigrizia , ed è garantito per essere thread-safe.

È corretto?

Answer 1

Il secondo snippet di codice è, a mio avviso, il modo migliore di inizializzare pigramente un singolo singolarmente. In realtà ha un nome di modello

Initialization-on-demand holder idiom

Vorrei suggerire lo si utilizza.

Answer 2

Il modo migliore è effettivamente usare il Enum Way:

public enum Singleton { 
    INSTANCE; 
    public void execute (String arg) { 
      //... perform operation here ... 
    } 
} 

Answer 3

Il secondo è molto male in termini di leggibilità, prima è adatta. Dai un'occhiata a questo article. Riguarda il doppio controllo del blocco, ma ti darà anche informazioni dettagliate sul multithreading dei singleton.

Answer 4

Il tuo primo progetto è in realtà pigro. Pensaci, l'istanza viene creata solo quando la classe è inizializzata; la classe viene inizializzata solo quando viene chiamato il metodo getSingleton() [1]. Quindi l'istanza viene creata solo quando viene richiesta, cioè è creata pigramente.

[1] http://docs.oracle.com/javase/specs/jls/se7/html/jls-12.html#jls-12.4.1

Answer 5

A mio parere, si tratta di un modello inadeguato per l'uso. Fa supposizioni sul comportamento della JVM che sono non banali e confuse. Inoltre, ha una classe fittizia. Le classi fittizie dovrebbero essere evitate quando possibile.

suggerisco l'approccio diretto:

public class Foo { 
    private volatile static final Foo instance = null; 

    private Foo() { 
    } 

    public static Foo instance() { 
     if (instance == null) instance = new Foo(); 
     return instance; 
     } 
    } 
} 

... anche se, questo non funziona così com'è - non è thread-safe .. cosa si vuole veramente è il modello doppio controllo presentato al punto 71 di Bloch Java efficace; vedi here.Adattamento dell'esempio al link al vostro caso, otteniamo:

public class Foo { 
    private volatile static final Foo instance = null; 

    private Foo() { 
    } 

    public static Foo instance() { 
     if (instance != null) return instance; 
     synchronized(instance) { 
      Foo result = instance; 
      if (instance == null) { 
       result = instance = new Foo(); 
      return result; 
     } 
    } 
} 

Note:

• Non preoccuparti per le prestazioni di questo codice, le JVM moderni prendono cura di esso ed è bene. Dopo tutto, premature optimization is the root of all evil.
• Come suggerito in altre risposte, quanto sopra non è la soluzione preferita di Bloch, ma penso che l'uso di un enum per un singleton sia semanticamente inappropriato proprio come l'OP in origine.