Es ist ein Beispiel von JCiP.

public class Unsafe {
    // Unsafe publication 
    public Holder holder;

    public void initialize() {
        holder = new Holder(42);
    }
}

public class Holder {
    private int n;

    public Holder(int n) {
        this.n = n;
    }
    public void assertSanity() {
        if (n != n) {
            throw new AssertionError("This statement is false.");
        }
    }
}

Auf Seite 34:

[15] Das Problem liegt hier nicht in der Holder-Klasse selbst, sondern darin, dass der Holder nicht ordnungsgemäß veröffentlicht wird. Holder kann jedoch immun gegen eine unsachgemäße Veröffentlichung gemacht werden, indem das n-Feld als endgültig deklariert wird, was Holder unveränderlich machen würde;

Und vondiese Antwort:

die Angabe für final (siehe @ andersojs Antwort) garantiert, dass bei der Rückkehr des Konstruktors das Feld final ordnungsgemäß initialisiert wurde (wie in allen Threads sichtbar).

Von wiki:

Wenn beispielsweise in Java ein Aufruf eines Konstruktors eingebunden wurde, wird die gemeinsam genutzte Variable möglicherweise sofort aktualisiert, nachdem der Speicher zugewiesen wurde, aber bevor der eingebundene Konstruktor das Objekt initialisiert.

Meine Frage ist

Weil: (könnte falsch sein, ich weiß es nicht.)

a) Die gemeinsam genutzte Variable kann sofort aktualisiert werden, bevor der eingebettete Konstruktor das Objekt initialisiert.

b) Das endgültige Feld wird garantiert NUR bei Rückkehr des Konstruktors ordnungsgemäß initialisiert (für alle Threads sichtbar).

Ist es möglich, dass ein anderer Thread den Standardwert von @ siehholder.n? (d. h. ein anderer Thread erhält einen Verweis aufholder Vor demholder Konstruktor gibt zurück.)

Wenn ja, wie erklären Sie dann die folgende Aussage?

Holder kann gegen eine unsachgemäße Veröffentlichung immun gemacht werden, indem das Feld n als endgültig deklariert wird, wodurch Holder unveränderlich wird

BEARBEITEN Von JCiP. Die Definition eines unveränderlichen Objekts:

Ein Objekt ist unveränderlich, wenn:
x Der Status kann nach der Erstellung nicht mehr geändert werden.

x Alle Felder sind final; [12] und

x Es wurde ordnungsgemäß erstellt (diese Referenz wird während der Erstellung nicht entfernt).

So per definitionem haben unveränderliche Objekte nicht "this Referenz Escape "Probleme. Richtig?

Aber sie leiden unter Außer Betrieb schreibt im Double-Checked-Locking-Muster, wenn nicht als flüchtig deklariert?