Sinn eines Singleton ?

[Werniman]

Hallo,
ich bin gerade wieder dabei, ein paar Sachen aus Büchern nachzubauen, um meine Kenntnisse zu erweitern. Dabei bin ich in einem Listing auf die Zeile
Calendar cal1 = Calendar.getInstance(); gestoßen, wobei ich mit dem getInstance nichts anfangen konnte. Beim Suchen im Netz habe ich rausgefunden,dass das ein sogenanntes Singleton ist,was immer dann genutzt werden soll,wenn es nur eine einzige Instanz einer Klasse geben soll und es Fehler gibt,wenn man weitere anlegt. Klingt erstmal logisch.

Testweise hab ich dann mal eine weitere Zeile eingefügt, wo sich nur der Name unterscheidet:
Calendar cal2 = Calendar.getInstance();

Nur...da ist kein Fehler. Hab ich da irgendwas falsch verstanden ?

 

[httpdigest]

Calendar.getInstance() liefert dir kein Singleton. Es ist eine einfache Factory Methode, die dir jedesmal eine neue Instanz einer Implementierung von Calendar (initialisiert mit der aktuellen Systemzeit) zurückliefert.

 

[mihe7]

Naja, getInstance liefert ja nur eine Referenz und die referenziert nur ein einziges Objekt.

Das Singleton-Pattern wird etwa so umgesetzt

class A {
    private static A instanz = new A();

    private A() {}
    public static A getInstance() { return instanz; }
}

 

[MoxxiManagarm]

Das Singleton-Pattern wird etwa so umgesetzt

Normalerweise so:

class A {
    private static A instanz = null;

    private A() {}

    public static A getInstance() { 
      if (instanz == null) instanz = new A();
      return instanz;
    }
}

Hat schlicht den Vorteil, dass du keine Instanz von A in der Laufzeit hast bevor sie benötigt wird

 

[mrBrown]

Hat schlicht den Vorteil, dass du keine Instanz von A in der Laufzeit hast bevor sie benötigt wird

Hat den Nachteil, nicht Threadsafe zu sein

public class A  {   
    private static class Holder {   
        public static final A instance = new A();
    }   

    private A() {}

    public static A getInstance() {   
        return Holder.instance;   
    }   
}

 

[MoxxiManagarm]

Hat den Nachteil, nicht Threadsafe zu sein

Synchronize?

 

[LimDul]

Synchronize?

Kostet Performance

 

[kneitzel]

Ja, um den ständigen synchronized check zu vermeiden halt eine doppelte Prüfung. Dann hat man so etwas:

public class A  { 
    private static Object lock = new Object();
    private static volatile A instance = null;

    private A() {}

    public static A getInstance() {
        if (instance == null) {
          synchronized(lock) {
              if(instance == null) instance = new A();
          }
        }
        return instance; 
    } 
}

Dann hat man halt das gewünschte lazy loading und keine ständigen Performance kostende synchronized checks.

 

[httpdigest]

Das Initialization-on-demand holder Pattern, das @mrBrown gezeigt hat, ist das performanteste von allen, da die Synchronisierung beim ersten (und nur beim ersten) Zugriff durch die JVM selbst bei der Klasseninitialisierung des Holders (durch den Zugriff auf das Holder.instance Feld) geschieht und dann nie wieder.
Tatsächlich erlaubt das `static final` noch viel weitreichendere Optimierungen durch den JIT. Z.B. werden dadurch alle Instanzen des Singletons an den Aufruferstellen ge-inlined.

 

[kneitzel]

Das Initialization-on-demand holder Pattern, das @mrBrown gezeigt hat, ist das performanteste von allen, da die Synchronisierung beim ersten (und nur beim ersten) Zugriff durch die JVM selbst bei der Klasseninitialisierung des Holders (durch den Zugriff auf das Holder.instance Feld) geschieht und dann nie wieder.
Tatsächlich erlaubt das `static final` noch viel weitreichendere Optimierungen durch den JIT. Z.B. werden dadurch alle Instanzen des Singletons an den Aufruferstellen ge-inlined.

Das ist ganz interessant. Das kannte ich so noch nicht muss ich gestehen. Und ich habe jetzt noch einmal nachgesehen: Auch in Entwurfsmuster von Kopf bis Fuß wird das so nicht erwähnt. Da werden auch nur vorzeitige Initialisierung oder eben der doppelte Check als Lösungen angeboten.

 

[mrBrown]

Das Initialization-on-demand holder Pattern, das @mrBrown gezeigt hat, ist das performanteste von allen

Ich finds auch einfach deutlich lesbarer, als irgendwelche Varianten mit synchronized und Double-checked-locking

 

[LimDul]

Das stimmt, das kannte ich auch nicht. Wobei ich persönliche auf die Vorzeitige Initialisierung nicht schlimm finde (sofern das Singleton höchstwahrscheinlich eh braucht)

Die synchronized Varianten mag ich auch nicht. Wer nicht weiß was er tut, baut schnell Code, der auf den ersten Blick Thread Safe aussieht aber auf den zweiten Blick entweder inperformant ist oder eben doch nicht thread safe. Und solche Fallstricke finde ich immer unschön.

 

[mrBrown]

Das schönste Singleton ist aber sowieso @Singleton class A {}

 

[httpdigest]

Vorzeitige Initialisierung

Das witzige dabei ist ja, dass hier gerade eben nichts vorzeitig vorinitialisiert wird. Die meisten JVMs (zumindest HotSpot, J9) laden Klassen sowieso lazy, wenn sie das erste Mal gebraucht werden; also wenn Code durchlaufen wird, der entweder die Klasse instanziiert oder eine statische Methode aufruft oder ein statisches Feld (das nicht mit einer Compile-time Konstanten initialisiert ist) anfässt. Hier ist letzteres der Fall. Der Singleton wird erst erzeugt, wenn auf das Feld tatsächlich zugegriffen wird.

 

[kneitzel]

Das schönste Singleton ist aber sowieso @Singleton class A {}

Wobei oft die Frage ist, was man wirklich erzwingen muss. In der Praxis habe ich oft nur eine Instanz, da das DI Framework eine Instanz erzeugt und bei jeder Anfrage ausliefert. Aber ja: da hat man kein Singleton mehr.