{"id":964,"date":"2016-03-22T17:15:27","date_gmt":"2016-03-22T15:15:27","guid":{"rendered":"http:\/\/invidit.de\/blog\/?p=964"},"modified":"2016-03-07T11:16:06","modified_gmt":"2016-03-07T09:16:06","slug":"einzigartiges-einzelstueck-der-vereinzelung","status":"publish","type":"post","link":"https:\/\/invidit.de\/blog\/einzigartiges-einzelstueck-der-vereinzelung\/","title":{"rendered":"Einzigartiges Einzelst\u00fcck der Vereinzelung"},"content":{"rendered":"

Hallo Spa\u00df-Coder.<\/p>\n

In unserem letzten Artikel zur Serie \u00fcber Entwurfsmuster haben wir uns mit der Erstellung von Produktfamilien besch\u00e4ftigt. In diesem Artikel werden wir uns nun um genau ein einziges Exemplar k\u00fcmmern. Es ist handelt sich um das sog. Einzelst\u00fcck <\/strong>(singleton<\/span>)<\/strong>.<\/i><\/p>\n

Wie die Abstract Factory <\/a>dient auch das Singleton dazu, ein Objekt zu erstellen, mit dem wir dann weiterarbeiten k\u00f6nnen. Aber warum wollen wir das? Hier gelten die gleichen Gr\u00fcnde, die wir auch schon bei der Abstrakten Fabrik angef\u00fchrt haben. Wir wollen m\u00f6glichst auf new<\/span> verzichten, wenn wir uns in Teilen des Codes bewegen, die sich mit hoher Wahrscheinlichkeit \u00e4ndern werden.<\/p>\n

Beim Singleton geht es darum, genau ein Objekt f\u00fcr unsere gesamte Anwendung zu erstellen. Egal an welcher Stelle wir uns das Singleton holen, es ist immer genau dasselbe<\/strong>. Wenn wir also an einer Stelle der Anwendung einen Status des Sinlgeton-Objekts setzen, hat es an anderer Stelle noch genau denselben Status.<\/p>\n

Wann aber ist dieses Entwurfsmuster sinnvoll anzuwenden?<\/p>\n

 <\/p>\n

Das gleiche ist noch lange nicht dasselbe<\/h1>\n

Das Singleton findet Verwendung, wenn wir in unser Anwendung zentral auf das gleiche Objekt zugreifen m\u00f6chten. Beispiele daf\u00fcr sind etwa zentrale Konfigurationen oder etwa eine Protokollausgabe, bei der wir von allen Stellen der Anwendung in dasselbe Protokoll schreiben wollen.<\/p>\n

Vereinfacht gesagt, immer dann, wenn nur ein Objekt zu einer Klasse existieren darf und ein einfacher Zugriff auf dieses Objekt ben\u00f6tigt wird, ist die Verwendung des Singleton-Musters sinnvoll.<\/p>\n

Beispiel<\/h2>\n

Schauen wir uns als Beispiel einmal an, wie wir einen zentralen Logger\u00a0 implementieren w\u00fcrden. Dazu erstellen wir eine Klasse Logger:<\/p>\n

public class Logger {\r\n\r\n    private static Logger instance;\r\n\r\n    private Logger() {\r\n    }\r\n\r\n    public static Logger getLogger() {\r\n        if (instance == null) {\r\n            instance = new Logger();\r\n        }\r\n        return instance;\r\n    }\r\n\r\n    public void Log(Object textToLog) {\r\n        System.out.println(textToLog);\r\n    }\r\n}<\/pre>\n
Der wichtigste Aspekt dieser Klasse ist, dass sie einen privaten Konstruktor<\/strong> enth\u00e4lt. Damit stellen wir sicher, das niemand eine Instanz dieser Klasse erstellen kann. Naja, wenigstens fast niemand. Eine Instanz brauchen wir schlie\u00dflich. Und wer hat Zugriff auf private Klassenmethoden? Genau, nur die Klasse selbst (und ihre inneren Klassen, aber darauf kommen wir bei einem anderen Muster nochmal zur\u00fcck). Das gilt in gleicher Weise f\u00fcr den Konstruktor.<\/p>\n
Nachdem wir nun also sichergestellt haben, dass nur wir eine Instanz unseres Loggers erstellen k\u00f6nnen, m\u00fcssen wir diesem aber auch zur\u00fcckgeben. Dazu enth\u00e4lt die Klasse eine statische<\/strong> Methode<\/strong> getLogger()<\/em>. Diese Methode dient dazu, die eine Instanz unseres Loggers abzurufen. Wird die Methode das erste Mal aufgerufen, so wird die Instanz erstellt. Von da an wird immer genau diese eine Instanz zur\u00fcckgegeben.<\/p>\n
Dadurch ist immer dann, wenn wir irgendwo in unserem Code eine Protokollausgabe machen m\u00f6chten sichergestellt, dass wir dieselbe Instanz der Klasse Logger<\/em> verwenden und somit immer an die gleiche Stelle protokollieren. Gut, oder?<\/p>\n
 <\/p>\n
Probleme des Singletons<\/h1>\n
Leider funktioniert unser obiger Code nicht gut. In kleinen, \u00fcberschaubaren Anwendungen, die nur in einem Thread arbeiten, ist unser Logger hinreichend gut. Versuchen wir aber nun mit zwei Threads gleichzeitig die Methode getLogger()<\/em> aufzurufen, bekommen wir ein Problem.<\/p>\n
Schaut euch den o.g. Code noch einmal an und geht im Kopf mal durch, was passiert, wenn zwei Threads gleichzeitig die Methode aufrufen. Erkennt ihr das Problem?<\/p>\n
Wenn zwei Threads gleichzeitig in die Methode eintreten, ist die Variable instance<\/em> f\u00fcr beide Threads null, es wird also jeweils eine Neue Instanz erstellt und zur\u00fcckgegeben. Diese sind dann nat\u00fcrlich unterschiedlich. Wie k\u00f6nnen wir das Problem l\u00f6sen?<\/p>\n
In Java hilft uns hier das Schl\u00fcsselwort synchronized<\/em> an der Methode:<\/p>\n
public synchronized static Logger getLogger() {\r\n\tif (instance == null) {\r\n\t\tinstance = new Logger();\r\n\t}\r\n\treturn instance;\r\n}<\/pre>\n
 <\/p>\n
In C# unterst\u00fctzt uns das Schl\u00fcsselwort lock, es ist aber ein wenig komplizierter zu verwenden. Hier ben\u00f6tigen wir noch ein Objekt, auf welchem wie die Sperre ausf\u00fchren k\u00f6nnen:<\/p>\n
private static Object locked = new Object();\r\n\r\npublic static Logger getLogger() {\r\n\tlock(locked) {\r\n\t\tif (instance == null) {\r\n\t\t\tinstance = new Logger();\r\n\t\t}\r\n\t\treturn instance;\r\n\t}\r\n}<\/pre>\n
Dadurch ist sichergestellt, dass auch wirklich nur eine Instanz erstellt wird, auch wenn aus unterschiedlichen Prozessen (Threads) heraus die Abfrage erfolgt.<\/p>\n
 <\/p>\n
Alles wird gut!<\/h2>\n
Damit ist alles gut, oder? Leider nicht. Wir haben zwar eine L\u00f6sung f\u00fcr das sog. Nebenl\u00e4ufigkeitsproblem gefunden, das kaufen wir aber teuer ein. Die Synchronisation von Code zwischen verschiedenen Prozessen ist teuer in der Laufzeit. Verwenden wir unser Singleton in unserer Anwendung h\u00e4ufig – und bei unserem Logger-Beispiel ist das nicht soo abwegig – hat das einen erheblichen schlechten Einfluss auf die Laufzeit unserer Anwendung.<\/p>\n
Wie aber wollen wir das Problem dann l\u00f6sen? Nun, zun\u00e4chst ist die Synchronisation tats\u00e4chlich der einzige Weg, das Problem der Nebenl\u00e4ufigkeit in den Griff zu bekommen. Wir k\u00f6nnen aber versuchen, das Problem mit der Performance in den Griff zu bekommen.<\/p>\n
1.) Nichts tun<\/strong><\/p>\n
H\u00e4? Wie jetzt? Seit wann l\u00f6sen wir Probleme durch aussitzen? Naja, ganz so ist es nicht. Wenn wir unsere Methode getLogger()<\/em> nur selten und nur in Performance-unkritischen Situationen verwenden, lassen wir den Code genau so wie er ist. Alles weitere ist unn\u00f6tige M\u00fche, die wir uns hier machen.<\/p>\n
2.) Instanz immer initialisieren<\/strong><\/p>\n
Wir k\u00f6nnen daf\u00fcr sorgen, dass unsere Instanz niemals null<\/em> ist. Dazu m\u00fcssen wir sie einfach beim Erstellen der Klasse instanziieren:<\/p>\n
public class Logger {\r\n\r\n    private static Logger instance = new Logger();\r\n [...]\r\n}<\/pre>\n
Da die Variable statisch ist, wird sie unmittelbar nach dem Laden der Klasse initialisiert. Ist also in unserem Beispiel immer mit einem Logger gef\u00fcllt. Das l\u00f6st das oben beschriebene Problem.<\/p>\n
Es k\u00f6nnte aber wieder zu einem neuen Problem f\u00fchren. N\u00e4mlich genau dann, wenn die Erstellung der Instanz sehr teuer ist, wir diese aber nicht immer in unserer Anwendung ben\u00f6tigen. Denken wir z.B. an eine Schnittstelle zu einem anderen System. Wird einer der Benutzer diese Schnittstelle anfragen? Lohnt es sich, die teure Initialisierung der Schnittstelle durchzuf\u00fchren, wenn wir das nicht wissen?<\/p>\n
Die Antwort ist nat\u00fcrlich „Nein“. Wir sollten in unserem Code nichts machen, was wir nicht auch brauchen.<\/p>\n
3.) Teilsynchronisation<\/strong><\/p>\n
Kommt f\u00fcr uns weder die erste, noch die zweite L\u00f6sung infrage, m\u00fcssen wir uns ein wenig M\u00fche geben, die Synchronisation so performant wie m\u00f6glich zu halten. Dazu synchronisieren wir nicht die ganze Methode, sondern lediglich die Erstellung unserer Instanz.<\/p>\n
Das Ganze sieht in Java dann wie folgt aus:<\/p>\n
public class Logger {\r\n\r\n    private volatile static Logger instance;\r\n\r\n    private Logger() {\r\n    }\r\n\r\n    public static Logger getLogger() {\r\n        if (instance == null) {\r\n            synchronized(Logger.class) {\r\n                if (instance == null) {\r\n                    instance = new Logger();\r\n                }\r\n            }\r\n        }\r\n        return instance;\r\n    }\r\n\r\n    public void Log(Object textToLog) {\r\n        System.out.println(textToLog);\r\n    }\r\n}<\/pre>\n
Wir pr\u00fcfen also zun\u00e4chst ohne Synchronisation, ob unsere Instanz schon gef\u00fcllt ist. Falls nicht, und nur in diesem Fall und nur genau einmal<\/strong>, f\u00fchren wir die Erstellung der Instanz synchronisiert durch. Damit die Abfrage auf die Variable aber auch thread\u00fcbergreifend funktioniert, ist es erforderlich, dass unsere Variable instance<\/em> mit dem Schl\u00fcsselwort volatile<\/em> versehen wird. Das sorgt daf\u00fcr, dass die Variable vor jedem Zugriff auf Aktualit\u00e4t gepr\u00fcft und ggf. aktualisiert wird. Dieser Vorgang ist wesentlich g\u00fcnstiger, als synchronize<\/em>.<\/p>\n
 <\/p>\n
In C# haben wir es nun ein wenig einfacher, da wir die Variable ja bereits definiert haben und wir ohnehin Bl\u00f6cke und nicht Methoden mit dem Schl\u00fcsselwort lock<\/em> verwenden:<\/p>\n
public class Logger {\r\n\r\n    private static Logger instance;\r\n\tprivate static Object locked = new Object();\r\n\r\n    private Logger() {\r\n    }\r\n\r\n    public static Logger getLogger() {\r\n        if (instance == null) {\r\n            lock(locked) {\r\n\t\t\t\tif (instance == null) {\r\n\t\t\t\t\tinstance = new Logger();\r\n\t\t\t\t}\r\n\t\t\t}\r\n        }\r\n        return instance;\r\n    }\r\n\r\n    public void Log(Object textToLog) {\r\n        System.out.println(textToLog);\r\n    }\r\n}<\/pre>\n
Die Funktionsweise ist hier identisch, nur brauchen wir kein weiteres Schl\u00fcsselwort f\u00fcr die Variable, da wir hier mit einem separaten Objekt arbeiten. Die Sprachkonzepte zwischen Java und C# sind ein wenig unterschiedlich, die Idee dahinter bleibt aber dieselbe.<\/p>\n
 <\/p>\n
Wichtig ist es bei der Suche nach der besten L\u00f6sung, sich zu vergegenw\u00e4rtigen, wie oft ich das Singleton ben\u00f6tige und wie aufwendig die Erstellung ist. Die L\u00f6sung ist dementsprechend der obigen M\u00f6glichkeiten zu w\u00e4hlen.<\/p>\n
 <\/p>\n
Warum muss immer ich das machen??<\/h1>\n
Wenn ein Framework eingesetzt wird, welches die Verwaltung von Singletons unterst\u00fctzt – z.B. das SpringFramework – sollte auf die eigene Implementierung verzichtet werden. Insbesondere bei komplexen Anwendungen mit Multithreading ist es – wie oben beschrieben – wichtig, dass das Singleton sauber implementiert ist. Wenn uns ein Framework diese Arbeit abnimmt, sollten wir dies auch nutzen.<\/p>\n
 <\/p>\n
Zusammenfassung<\/h1>\n
Das Singleton ist ein wichtiges uns sehr hilfreiches Muster. Es hat seine T\u00fccken, aber wenn man diese kennt, sind sich auch kein gr\u00f6\u00dferer Schrecken mehr als Knecht Ruprecht, nachdem man erfahren hat, dass er in Wirklichkeit gar nicht existiert.<\/p>\n
Wir hoffen, dass die Beispiele euch gen\u00fcgend Anhaltspunkte daf\u00fcr gegeben haben, wann und insbesondere wie das Muster sinnvoll eingesetzt werden kann.<\/p>\n
Viel Spa\u00df beim Ausprobieren<\/p>\n
Eure Spa\u00df-Coder<\/p>\n
 <\/p>\n
Den Code zu unserem Beispiel k\u00f6nnt ihr auf Github finden:<\/p>\n