In diesem Artikel wird erläutert, wie das Singleton-Muster erzwingt, dass nur eine einzige Instanz einer Klasse jemals erstellt wird und während der Lebensdauer einer Anwendung existiert.

Was ist es?

Ein Singleton ist ein Entwurfsmuster, das verwendet wird, um die einzige Klasseninstanz zu erstellen. Singleton-Muster werden normalerweise verwendet, wenn es mehrere Beispiele gibt, bei denen nur eine einzige Instanz einer Klasse vorhanden sein soll und die Einschränkung erzwungen werden soll. Beispielsweise sollten Caches, Thread-Pools und Registrierungen nur eine Instanz haben.

Machen Sie den Konstruktor privat, um sicherzustellen, dass nur ein Klassenobjekt erstellt wird. Auf diese Weise können nur die Klassenmitglieder auf den privaten Konstruktor zugreifen und sonst niemand.

In der realen Welt sorgt das Singleton-Pattern dafür, dass nur eine einzige Klasseninstanz existiert und bietet einen globalen Zugriffspunkt darauf.

Klassen Diagramm

Das Klassendiagramm enthält nur eine Entität.

Einzelling

Beispiel

Angenommen, wir möchten das offizielle Flugzeug des amerikanischen Präsidenten namens Airforce One in unserer Software modellieren. Die Singleton-Klasse ist die am besten geeignete Darstellung für eine Entität mit nur einer Instanz.

Hier ist der Code für unsere Singleton-Klasse:

Multithreading und Singleton

Dieser Code funktioniert, solange die Anwendung Singlethreading ist. Wenn jedoch mehrere Threads auf diese Klasse zugreifen, besteht die Möglichkeit, dass verschiedene Objekte erstellt werden.

Zum Beispiel:

• Thread A ruft die Methode auf getInstanceund stellt fest, dass onlyInstancenull ist; Bevor jedoch eine Instanz erstellt werden kann, wird der Kontext ausgeschaltet.
• Jetzt kommt Thread B daher und ruft auf , was das Objekt getInstancezurückgibt .AirforceOne
• Wenn Thread A neu geplant wird, beginnt der Unfug. Der Thread hat die If-Null-Bedingungsprüfung bereits hinter sich und wird mit der Erstellung eines neuen AirforceOneObjekts fortfahren und es zuweisen onlyInstance. Jetzt gibt es zwei verschiedene AirforceOneObjekte in freier Wildbahn, eines mit Faden A und eines mit Faden B.

• Indem Sie synchronizeddie getInstance()Methode ergänzen, können Sie Fadensicherheit erreichen.

• Eine andere Möglichkeit besteht darin, die Instanz statisch zu initialisieren, um sicherzustellen, dass sie Thread-sicher ist.

Doppelt geprüfte Verriegelung

Bei den oben beschriebenen Ansätzen gibt es zwei wesentliche Probleme: Die Synchronisierung ist teuer, und die statische Initialisierung erstellt das Objekt, selbst wenn es in einem bestimmten Anwendungslauf nicht verwendet wird. Wenn die Objekterstellung teuer ist, kann uns die statische Initialisierung Leistung kosten.

Die obige Lösung markiert die Singleton-Instanz als flüchtig. Diese Implementierung der JVM- volatileMethodik funktioniert jedoch nicht korrekt für doppelt geprüftes Sperren, und Sie benötigen einen anderen Ansatz, um Ihre Singletons zu erstellen.

Das Double-Checked- Locking-Idiom gilt jetzt als Anti-Pattern, und seine Nützlichkeit ist in erster Linie verschwunden, da sich die Startzeiten von JVM beschleunigt haben.

Andere Beispiele

Die Java-API stellt uns die folgenden Singletons zur Verfügung:

java.lang.Runtime

java.awt.Desktop

Vorbehalte

Sie können eine Singleton-Klasse ableiten, indem Sie den Konstruktor anstelle von private schützen. Es gibt jedoch unter allen Umständen bessere Möglichkeiten als diese. In diesen Situationen können Entwickler eine Registrierung von Singletons für alle Unterklassen erstellen. Die getInstance-Methode kann einen Parameter aufnehmen oder eine Umgebungsvariable verwenden, um das gewünschte Singleton-Objekt zurückzugeben. Die Registrierung verwaltet eine Zuordnung von Zeichenfolgennamen zu Singleton-Objekten.

Weitere Artikel in der Creational Pattern-Reihe

• Schöpfungsmuster: Erbauer
• Schöpfungsmuster: Prototyp
• Schöpfungsmuster: Fabrikmethode
• Schöpfungsmuster: Abstrakte Fabrik