[code]
/**
* Implementierung des Singleton-Patterns mit synchronisiertem
* Zugriff auf die Instanziierung und einfacher Bedingungsprüfung
*/
public class VerySingleton {
private static VerySingleton instance = null;
private static Boolean created = false;
/**
* Default-Konstruktor, der nicht außerhalb dieser Klasse
* aufgerufen werden kann
*/
private VerySingleton() {}

/**
* Statische Methode, liefert die einzige Instanz dieser
* Klasse zurück
*/
public static VerySingleton getInstance() {
if (!created) {
synchronized(VerySingleton.class) {
if(!created)
instance = new VerySingleton();
created = true;
}
}
return instance;
}
}
[/code]

Da ich etwas verwirrt von dem komplizierten Satz war, und der Kommentar vom E.L auch nicht ganz korrekt ist, hier meine Version:

“Die *erste* Bedingung if (instance == null) in Zeile *21* kann nämlich im Thread B zu “FALSE” evaluieren, *bevor* der Konstruktor DoubleCheckedLockingSingleton() im Thread A fertig wird (und somit eine Instanz die zwar nicht null ist, aber noch nicht abgeschlossen-initialisiert wurde zurückgeben). In diesem Fall wird im zweiten Thread mit einem nicht (abgeschlossen-initialisierten “Objekt” gearbeitet!”

Und entsprechend den Satz:

“Die zweite Bedingung if (instance == null) würde damit zu true evaluieren, ohne daß bisher der Konstruktor (Zeile 6) aufgerufen worden wäre.”

ändern in den

“Die *erste* Bedingung if (instance == null) in Zeile *21* kann nämlich im Thread B zu FALSE evaluieren, *bevor* der Konstruktor DoubleCheckedLockingSingleton() im Thread A abgeschlossen wird. In diesem Fall wird im Thread B mit einem nicht abgeschlossen-initialisierten “Objekt” gearbeitet!”

Das war einfach, erledigt – thanks :-)

Anmerkungen zu “Double-checked locking”:

1) mit dem Speichermodell der Java-Plattform hat das nichts zu tun. Das ist einfach so allgemein möglich, dass es zunächst der Referenz die Adresse des allozierten Speicher zugewiesen und erst danach der Konstruktor aufgerufen wird.

2) statt
“Die zweite Bedingung if (instance == null) in Zeile 23 kann nämlich zu true evaluieren, ohne daß new DoubleCheckedLockingSingleton() aufgerufen, und das instanziierte Objekt dem Klassenattribut instance zugewiesen wurde!”

sollte es ungefähr so heißen :
“Die *erste* Bedingung if (instance == null) in Zeile *21* kann nämlich im zweiten Thread zu true evaluieren, *bevor* der Konstruktor DoubleCheckedLockingSingleton() im ersten Thread aufgerufen wird. In diesem Fall wird im zweiten Thread mit einem nicht (korrekt) initialisierten “Objekt” gearbeitet!”

Siehe:
http://en.wikipedia.org/wiki/Double-checked_locking

Der Artikel ist schön geschrieben.

Danke schön :-)

Die von Ihnen genannten Nachteile existieren in der Tat. Als das Singleton-Pattern in der Java-Welt seinen Einzug gefunden hat, waren Testing-Frameworks � la JUnit nicht/kaum existent, so – und das ist meine Interpretation – daß das automatisierte Testing im Hintergrund stand.
Das Inversion of Control Pattern hingegen gibt es erst seit wenigen Jahren (2-3?) und kann einige der Probleme lösen. IoC wird auch Thema einer meiner (oder Ihrer? :-)) nächsten Artikel sein.

Eigentlich ist ein Sigleton als Objekt-Muster gedacht. Die dargestellte Implementierung stellt zwar sicher, dass es nur eine Instanz der Klasse geben kann, aber als Nebeneffekt ist diese Instanz damit auch global verfügbar.

Eberhard Wolf schreibt in Vom Pattern zum Anti-Pattern:

Wenn das Singleton dann noch in anderen Klassen direkt im Code oder versteckt in Feld-Initialisierungen oder Konstruktoren referenziert wird, dann ist isoliertes Testen unmöglich.