Ein Singleton — wenn überhaupt — soll funktionieren und schnell sein. Oder um genau zu sein eine Singleton-Factory — also ein Singleton mit Lazy-Intialization. Das ist aber nicht so leicht so programmieren, wie man vielleicht glaubt…
Wenn es sicher sein soll, braucht man irgendwie ein synchronized? Und damit es schneller wird, wickelt das kostenintensive synchronized noch in einen schnellen if-Check (Doubly Checked locking).
Achtung: der folgende Code ist kaputt:
public class UnsafeDCLFactory {
private Singleton instance;
public Singleton get() {
if (instance == null) {
synchronized (this) {
if (instance == null) {
instance = new Singleton();
}
}
}
return instance;
}
}
Warum der kaputt ist, steht ausführlich hier.
Ja, Singletons sind niemals so leicht zu implementieren, wie man hofft (das ist in C++ übrigens mindestens genauso schlimm).
Es gibt aber mehrere Lösungen der Probleme (siehe obiger Link). Ich möchte hier nur die eine zeigen, die ich mir persönlich leicht merken kann, und zufälligerweise auf einen x86er auch noch die schnellste ist:
public class HolderFactory {
public static Singleton get() {
return Holder.instance;
}
private static class Holder {
public static final Singleton instance = new Singleton();
}
}
Auch dies ist lazy, denn die Klasse Holder wird mit seinen statischen Feldern erst bei der ersten Verwendung (in get()) initialisiert. Und siehe da, es kommt ohne ein selbstprogrammiertes synchronized aus. Ok, die JVM macht das versteckt, aber die Messwerte zeigen, es ist 3x so schnell wie die Ansätze, die volatile oder synchronized verwenden.
Der Artikel Safe Java Singletons? erschien zuerst auf icancode.de.