Disclaimer: ho appena sintetizzato tutte le risposte fantastiche e l'ho scritto con le mie parole.
Durante l'implementazione di Singleton abbiamo 2 opzioni
1. Caricamento lento
2. Caricamento anticipato
Il caricamento lento aggiunge un po 'di sovraccarico di bit (molti ad essere sinceri) quindi usalo solo quando hai un oggetto molto grande o un codice di costruzione pesante E hai anche altri metodi o campi statici accessibili che potrebbero essere utilizzati prima che sia necessaria un'istanza, quindi e solo allora è necessario utilizzare l'inizializzazione lenta. In caso contrario, scegliere il caricamento anticipato è una buona scelta.
Il modo più semplice per implementare Singleton è
public class Foo {
// It will be our sole hero
private static final Foo INSTANCE = new Foo();
private Foo() {
if (INSTANCE != null) {
// SHOUT
throw new IllegalStateException("Already instantiated");
}
}
public static Foo getInstance() {
return INSTANCE;
}
}
Tutto è buono tranne il suo singleton caricato in anticipo. Proviamo singleton caricato pigro
class Foo {
// Our now_null_but_going_to_be sole hero
private static Foo INSTANCE = null;
private Foo() {
if (INSTANCE != null) {
// SHOUT
throw new IllegalStateException("Already instantiated");
}
}
public static Foo getInstance() {
// Creating only when required.
if (INSTANCE == null) {
INSTANCE = new Foo();
}
return INSTANCE;
}
}
Fin qui tutto bene, ma il nostro eroe non sopravviverà combattendo da solo con più fili malvagi che vogliono molti esempi del nostro eroe. Quindi, consente di proteggerlo dal multi threading male
class Foo {
private static Foo INSTANCE = null;
// TODO Add private shouting constructor
public static Foo getInstance() {
// No more tension of threads
synchronized (Foo.class) {
if (INSTANCE == null) {
INSTANCE = new Foo();
}
}
return INSTANCE;
}
}
ma non è abbastanza per proteggere l'eroe, Davvero !!! Questo è il meglio che possiamo / dovremmo fare per aiutare il nostro eroe
class Foo {
// Pay attention to volatile
private static volatile Foo INSTANCE = null;
// TODO Add private shouting constructor
public static Foo getInstance() {
if (INSTANCE == null) { // Check 1
synchronized (Foo.class) {
if (INSTANCE == null) { // Check 2
INSTANCE = new Foo();
}
}
}
return INSTANCE;
}
}
Questo è chiamato "Idioma di blocco a doppio controllo". È facile dimenticare l'affermazione volatile e difficile capire perché sia necessario.
Per dettagli: http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html
Ora siamo sicuri del filo diabolico ma della crudele serializzazione? Dobbiamo assicurarci che anche durante la deserializzazione non venga creato alcun nuovo oggetto
class Foo implements Serializable {
private static final long serialVersionUID = 1L;
private static volatile Foo INSTANCE = null;
// Rest of the things are same as above
// No more fear of serialization
@SuppressWarnings("unused")
private Object readResolve() {
return INSTANCE;
}
}
Il metodo readResolve()assicurerà che venga restituita l'unica istanza, anche quando l'oggetto è stato serializzato in una precedente esecuzione del nostro programma.
Finalmente abbiamo aggiunto una protezione sufficiente contro i thread e la serializzazione, ma il nostro codice sembra voluminoso e brutto. Diamo un cambio al nostro eroe
public final class Foo implements Serializable {
private static final long serialVersionUID = 1L;
// Wrapped in a inner static class so that loaded only when required
private static class FooLoader {
// And no more fear of threads
private static final Foo INSTANCE = new Foo();
}
// TODO add private shouting construcor
public static Foo getInstance() {
return FooLoader.INSTANCE;
}
// Damn you serialization
@SuppressWarnings("unused")
private Foo readResolve() {
return FooLoader.INSTANCE;
}
}
Sì, questo è il nostro stesso eroe :)
Dato che la linea private static final Foo INSTANCE = new Foo();viene eseguita solo quando la classe FooLoaderviene effettivamente utilizzata, questo si occupa dell'istanza pigra,
ed è garantito per essere thread-safe.
E siamo arrivati così lontano, ecco il modo migliore per ottenere tutto ciò che abbiamo fatto è il modo migliore possibile
public enum Foo {
INSTANCE;
}
Quale internamente sarà trattato come
public class Foo {
// It will be our sole hero
private static final Foo INSTANCE = new Foo();
}
Questo è tutto! Niente più paura della serializzazione, dei thread e del brutto codice. Anche ENUMS singleton sono inizializzati pigramente .
Questo approccio è funzionalmente equivalente all'approccio di campo pubblico, tranne per il fatto che è più conciso, fornisce gratuitamente i macchinari di serializzazione e fornisce una garanzia coraggiosa contro l'istanza multipla, anche di fronte a sofisticati attacchi di serializzazione o di riflessione. Mentre questo approccio deve ancora essere ampiamente adottato, un tipo enum a elemento singolo è il modo migliore per implementare un singleton.
-Joshua Bloch in "Efficace Java"
Ora potresti aver capito perché ENUMS è considerato il modo migliore per implementare Singleton e grazie per la tua pazienza :)
Aggiornato sul mio blog .