Double-Checked Locking

[SlaterB]

hallo,

ich finde den Artikel
The "Double-Checked Locking is Broken" Declaration
nicht genau genug (edit: bzw. möchte nicht alle referenzierten Links auch noch lesen ),

ich kann mir gut vorstellen dass er richtig ist, wäre mit deutlicheren Erklärungen aber noch zufriedener,
es geht um 'lazy initialization in a multithreaded environment', also mit Synchronisation

die erste ernstzunehmende Version

class Foo {
    private Helper helper = null;

    public Helper getHelper() {
        if (this.helper == null) {
            synchronized (this) {
                if (this.helper == null) {
                    this.helper = new Helper();
                }
            }
        }
        return this.helper;
    }
}

wird abgelehnt mit (nach meinem Verständnis) der Begründung, dass die Variable helper schon gesetzt wird,
bevor der Konstruktor von Helper komplett ausgeführt wird,

nach welchen internen Optimierungsgründen auch immer, das finde ich nicht schön, kann ich aber halbwegs akzeptieren,
da es aus lokaler Sichtweise hinkommt, bevor die nächste Code-Zeile drankommt wird schon alles fertig sein,
Reihenfolge wäre für nur einen Thread relativ egal

-----

das folgende Beispiel im Artikel ist mir dann schon bisschen zu kompliziert,
enthält nebenher auch langweilige doppelte Synchronisation,

der spannendere Teil ist für mich die Nutzung einer lokalen Variable, ein verkürzter Code:

class Foo {
    private Helper helper = null;

    public Helper getHelper() {
        if (this.helper == null) {
            synchronized (this) {
                if (this.helper == null) {
                    Helper h = new Helper();
                    this.helper = h;
                }
            }
        }
        return helper;
    }
}

die ablehnende Begründung im Artikel kümmert sich mehr um die doppelte Synchronisation usw.,
ich frage mich aber ob nicht allein die lokale Variable hilft, das Problem des ersten Beispiels zu beheben?
kann nicht in Zeile 9 davon ausgegangen werden dass das Objekt h komplett initialisiert ist?
denn wenn nicht, dann hätte man ja bei jedem lokal erzeugten Objekt das Problem, dass es in der nächsten Zeile vielleicht noch nicht sauber erstellt ist..,

in speziell diesem Fall kann man vielleicht wieder böse Optimierungen vermuten, etwa dass die lokale Variable h komplett rausfällt
und der Code exakt zur Variante 1 'verbessert' wird, ist das noch das verbleibende Problem?

aber man kann zwischen Zeile 8 und 9 ja noch mehr Code einfügen, z.B. eine Ausgabe der Attribute oder hashCode()-Aufruf,
danach richten sich doch hoffentlich die denkbaren Befehlsvertauschungen?

strenggenommen wäre dann denkbar, dass der Code immer noch zu

this.helper = new Helper();
// Ausgaben oder irgendein Aufruf an this.helper

optimiert wird?,
mit den gleichen Problemen für andere Threads am Anfang mit uninitialisierten this.helper
aber durchaus funktionierenden Ausgaben später

-----

dann würde ich weiterdenken:
Hilfsmethoden an sich helfen vielleicht nicht, immer mit dem Totschlagargument dass deren Code einfach herüberkopiert wird..,
eine Initialisierungsklasse wäre ziemlich heftig, mit Konstruktor und get-Methode, das kann doch kaum alles herausgezogen werden,
da ich aber danach noch andere Ideen hatte erspare ich erst mal den langen Code mit Erklärungen dazu

zurück nur zur Klasse Foo, nur getHelper dort, in synchronized im if zu den entscheidenen Zeilen:

this.helper = new Helper();

soll schlecht sein

Helper h = new Helper();
this.helper = h;

soll auch schlecht sein

wie steht es mit folgendem:

this.helper = new Helper().returnYourself();

mit einer Methode returnYourself() die nur sich selbst, also this zurückgibt,
kann dieser eigentlich sinnlose Methodenaufruf wegoptimiert werden?
wenn nicht, kann die Methode ausgeführt werden bevor das Helper-Objekt vollständig initialisiert ist?

und hoffentlich steht doch wohl in der Variable this.helper nichts drin, bevor nicht die Methode returnYourself() ausgeführt wurde?


oder noch eine Variante:

Helper h = new Helper();
this.helper = h.hashCode() < Integer.MAX_VALUE ? h : null;

mal abgesehen von der Frage ob der Hashcode vielleicht doch Integer.MAX_VALUE ist,
ist es irgendwie denkbar dass die Methode hashCode() vor kompletter Initialisierung von h ausgeführt wird?
oder auf andere Weise der ganze Block übersprungen wird?


-------

dann noch die Möglichkeit, das Objekt nicht direkt abzulegen sondern in einer List/ Map zu speichern,
Java wird doch wohl nicht wagen, dorthin ein uninitialisiertes Objekt zu übergeben?

warum wird im Artikel soweit ich das sehe auf derartiges nicht eingegangen?
die Varianten mit ThreadLocal oder Guard<LOCK> scheinen mir höchst kompliziert,
als wäre generell nichts möglich und nur zum Spaß werden akademische Versionen gezeigt

volatile und Immutable sind am Ende immerhin noch saubere Lösungen

 

[faetzminator]

Ich hab nicht alles durchgeschaut, aber nicht eher

class Foo {
    private Helper helper = null;
 
    public Helper getHelper() {
        if (this.helper == null) {
            synchronized (this) {
                Helper h = new Helper();
                if (this.helper == null) {
                    this.helper = h;
                }
            }
        }
        return helper;
    }
}

?

 

[Marco13]

Den Artikel hatte ich auch mal ... "gelesen". Aber es stimmt: Besonders genau ist er nicht, und wenn man die "entmutigenden" ersten Worte liest, und dann so drüberscrollt, und die Überschriften liest:

It does not work
Lorem ipsum...
It really does not work
Dolor sit amet...
It really does never work
Lorem ipsum...
It really does not work and will never work, get over it
Dolor sit amet...

How it works, anyhow:

...

Ist die Versuchung schon groß, das einfach zu akzeptieren und den Code am Ende zu verwenden

Detaillierte Begründungen, quasi der komplette "Erklär-Baum" jedes einzelnen Aspekts oder vermeintlichen Workarounds bis runter zu den "Blättern" (einzelnen Zeilen und Paragraphen in der JVM Specification) wären mir dann auch zu viel.

kann nicht in Zeile 9 davon ausgegangen werden dass das Objekt h komplett initialisiert ist?
denn wenn nicht, dann hätte man ja bei jedem lokal erzeugten Objekt das Problem, dass es in der nächsten Zeile vielleicht noch nicht sauber erstellt ist..,
...

Meinem Verständnis nach trifft das zu, was du beschrieben hast: Einerseits könnte die lokale Variable vermutlich rausfallen. Zusätzlich können wohl die Anweisungen (d.h. das Initialisieren der Fields im Konstruktor und das Zuweisen des neuen Objektes an die Hilfsvariable, und deren Zuweisung ans Field(!)) beliebig umsortiert werden.

Die Sache mit dem
[c]this.helper = new Helper().returnYourself();[/c]
ist aber schon ein interessanter Gedanke. Da man nicht weiß, WAS der Compiler oder JIT genau optimiert, kann man da eigentlich nur drüber spekulieren. Theoretisch(!) könnte er die Semantik dort erkennen, und theoretisch könnte er es
[c]this.helper = new Helper();[/c]
zusammenschrumpfen, aber erstens ist das praktisch kaum machbar (weil in der "returnYourself" ja auch mehr stehen könnte, als das 'return') und zweitens wäre so eine Optimierung, die das Verhalten (auch in bezug auf SO einen speziellen und heiklen Punkt) ändern würde ziemlich fragwürdig. Noch extremer wäre das mit dem HashCode, was beides plakativ formuliert ja das Ziel erreichen soll, was man als

Helper h = new Helper();
while (!h.isCompletelyInitialized()) { / * Do nothing */ }
this.helper = h;

schreiben könnte (und was nichtmal unbedingt Pseudocode sein soll, weil es ja den gleichen Effekt erzielen könnte...)

Ab einem bestimmten Punkt drängt sich da schon die Frage auf, welche Krämpfe man sich antun will, und die Frage (bzw. nicht so sehr die eigentlich Frage, sondern die Kette der sich aus möglichen Workarounds ergebenden Fragen) erscheint irgendwann akademisch. Aber ... es wäre schon gut, es genauer zu wissen.
Bin mal gespannt ob noch jemand weniger Spekulationen als mehr konkrete Erleuchtung bringt....:rtfm:

 

[SlaterB]

danke schonmal, und wie Otto so sagt:
einen hab ich noch, vielleicht am gebräuchlichsten (wer will schon returnYourself() in vielen Klassen)

this.helper = RealHelper.initialize(new Helper());

mit nur einer zentralen statischen Hilfsmethode, die dann nun richtig ernst rangehen darf, ob Hashcode, Random, Reflection, Einfügen in Liste + Herausholen oder was auch immer,
Aufwand halbwegs egal, hauptsache am Ende wird dasselbe Objekt zurückgegeben

 

[Lumaraf]

Die Sache mit dem
[c]this.helper = new Helper().returnYourself();[/c]
ist aber schon ein interessanter Gedanke. Da man nicht weiß, WAS der Compiler oder JIT genau optimiert, kann man da eigentlich nur drüber spekulieren. Theoretisch(!) könnte er die Semantik dort erkennen, und theoretisch könnte er es
[c]this.helper = new Helper();[/c]
zusammenschrumpfen, aber erstens ist das praktisch kaum machbar (weil in der "returnYourself" ja auch mehr stehen könnte, als das 'return') und zweitens wäre so eine Optimierung, die das Verhalten (auch in bezug auf SO einen speziellen und heiklen Punkt) ändern würde ziemlich fragwürdig. Noch extremer wäre das mit dem HashCode, was beides plakativ formuliert ja das Ziel erreichen soll, was man als

Java 7 kann diese Optimierungen soweit ich weiß vornehmen. Unter Java 6 bin ich mir nicht sicher ob der Fall da schon abgedeckt wird. Dazu kommt noch das die CPU sich an der Ausführungsreihenfolge auch noch austobt. Die Reihenfolge kann sich sogar während die JVM läuft ändern.

Im Endeffekt hat man nur eine der folgenden Möglichkeiten:
1. auf Double-Checked Locking verzichten und sich auf die lazy Initialisierung der Klassen verlassen
2. das Instanz-Feld volatile deklarieren
3. die Instanz in eine AtomicReference kapseln

Die erste Möglichkeit ist allen anderen überlegen da sie ja keine Überprüfung machen muß ob die Instanz schon erzeugt wurde, die Instanz wird aber trotzdem erst erzeugt wenn man sie das erste mal benötigt.