Diskussion:Liste von Singleton-Implementierungen

C#

Ich finde die C# Implementierungen nicht gerade schön, verwendet man nicht eher ein Getter als ein Funktion (getInstance())? IceOnly 00:43, 15.05.2011 (CEST)

Ich habe die Variante 2 des C#-Beispiels aus dem Artikel entfernt ([1]), da sie (denke ich) fehlerhaft ist.

Grund ist, dass beim Lesen des Wertes eine memory barrier fehlt.

Wenn man jetzt einen Thread hat, der nach instance schreibt:

• 1. Daten des neu erzeugeten Objekts in den Speicher schreiben
• 2. Eine MemoryBarrier
• 3. Die Referenz nach instance schreiben

und einen, der instance ausliest:

• A. Referenz aus instance auslesen
• B. Daten des Objekts lesen

dann darf die Runtime dies folgendermaßen anordnen:

• B.
• 1.
• 2.
• 3.
• A.

so dass beim Schritt B nicht-initialisierte Daten (bzw. Nullen) gelesen werden.

B darf hierbei über 2 verschoben werden, weil es in einem anderen Thread ist (und die Barrier nur für einen Thread gilt).

B kann (zumindest aus globaler Sicht) vor A ausgeführt werden wenn z.B. ein Objekt, das im Speicher direkt neben dem Singleton liegt, gelesen wird und dadurch die Daten schon in den Prozessorcache gelesen werden.

88.67.88.127 20:34, 25. Feb. 2008 (CET)

Ich habe die C#-Beispiele überarbeitet und erweitert. Sollte jetzt besser sein. — MovGP0 04:13, 13. Apr. 2013 (CEST)

Python

Das Python Borg Pattern war kaputt(tm) ("inst" wurde nicht returned). Habe das mal gefixt. 84.58.191.156 00:44, 1. Dez. 2006 (CET)

C++ Code

Habe ein paar Dinge verschönert, denn so war der Code nicht mal compilierbar. Finde auch daß ein oder zwei Beispiele reichen, z.B. Java und C++. (nicht signierter Beitrag von 193.16.191.2 (Diskussion) 09:48, 21. Sep. 2010 (CEST))

Also mit C++ bin ich nicht vertraut, aber zB. die generischen C#-Beispiele sind nicht gerade trivial, weshalb es nicht schadet ein paar Beispiele mehr zu geben. Es reicht aber sicher ein Beispiel pro Variante. — MovGP0 04:14, 13. Apr. 2013 (CEST)

Das meyers singleton ist thread safe in c++11 Jwalter (Diskussion) 00:28, 29. Jul. 2016 (CEST)

Zum Abschnitt "Alternative Implementierung mit Enum in Java ab Version 5"

Die Realisierung mit enum verhindert, dass man das Singleton von einem anderen Objekt außer Object vererben kann.

public enum Singleton extends AnyObject {
  INSTANCE;
}

liefert einen Fehler, da in Enums ein

extends

nicht möglich ist. Die Realisierung kann man also nur eingeschränkt benutzen. --Florian Hurlbrink (Diskussion) 12:54, 22. Okt. 2010 (CEST)

Defekter Weblink

Dieser Baustein verhindert die automatische Archivierung dieses Abschnitts und seiner Unterabschnitte.

Der folgende Weblink wurde von einem Bot („GiftBot“) als nicht erreichbar erkannt.
Ausführliche Erläuterungen und Hilfe zur korrekten Behebung dieses Fehlers finden sich auf Wikipedia:Defekte Weblinks. Ist ein von einem Bot als defekt gemeldeter externer Link doch erreichbar, dann bitte berichten – wie auch sonstige Probleme.

• http://docs.oracle.com/javase/specs/jvms/se5.0/html/Concepts.doc.html#19075
  • Vielleicht ist eine archivierte Version geeignet: archive.orghttp://giftbot.dwl.invalid/http://docs.oracle.com/javase/specs/jvms/se5.0/html/Concepts.doc.html#19075

– GiftBot (Diskussion) 02:18, 10. Feb. 2016 (CET)

Lazy java singletons

Die Beschriebene synkronisierung der Klassenmethode wurde gut fatalisiert. Jedoch ist die empfohlene Methode nur im idealfall Lazy da mit reflection ein vorzeitiges laden der klasse und dem entstehen der Instanz ein Nebeneffekt sein. Lazy in dem Fall nicht korrekt sondern eher Dozily. Auch wird das problem nicht behoben weil das laden von Klassen sowieso auf den classloader synkronisiert ist, ebenso wie eine synkronisierte methode. Besser ist

   public final class Singleton{
     private static Singleton INSTANCE = null;
     public static Singleton getInstance() {
       if (INSTANCE != null){
         return INSTANCE;
       }
       synchronized(Singleton.class) {
         if(INSTANCE != null){
           return INSTANCE;
         }
         return INSTANCE==new Singleton();
       }
     }
     private Singleton(){}
   }

Das ist Lazy im Sinne des spätesten instanziierung. (nicht signierter Beitrag von 92.230.142.220 (Diskussion) 08:39, 21. Aug. 2016 (CEST))

Der Einwand mit dem frühen Laden per Reflection ist durchaus berechtigt und sollte im Text erwähnt werden. Dein Ansatz mit Double-Checked-Locking wird ohne volatile aber nicht sauber funktionieren.--Der Hâkawâti ✉ 16:24, 21. Aug. 2016 (CEST)