Java Memory Model Die Initialisation-Safety-Garantie für final-Felder von primitivem Typ   Java Magazin, Februar 2009 Klaus Kreft & Angelika Langer

Dies ist das Manuskript eines Artikels, der im Rahmen einer Kolumne mit dem Titel "Effective Java" im Java Magazin erschienen ist.  Die übrigen Artikel dieser Serie sind ebenfalls verfügbar ( click here ).   Die ganze Serie zum  "Java Memory Modell" als PDF (985 KB).

Wir haben in einem der vorangegangenen Beiträge [ EFF2 ] erwähnt, dass es besondere Garantieren für die Sichtbarkeits- und Speichereffekte im Zusammenhang mit final gibt.  Diese Garantien wollen wir uns in diesem Beitrag genauer ansehen.
 

Racy-Single-Check mit einem primitiven Typ (außer long und double)

Hier noch einmal unser Beispiel des Racy-Single-Check -Idioms aus unserem letzten Artikel:

public class MyClass {
    private int lazyField;
    ...

    public int getMyField() {
        if (lazyField == 0)
            lazyField = 10000;

        return lazyField;
    }

    ...
}

• Der Zugriff auf das fragliche Feld muss atomar sein. Sonst wäre der Zugriff unterbrechbar und das Feld könnte (aus Sicht des lesenden Threads) sinnlose Werte enthalten. Die Ununterbrechbarkeit des Zugriffs auf primitive Typen (außer long und double) ist in Java garantiert.
• Das Feld lazyField ändert sich nach der Initialisierung nicht mehr.   Man würde es gerne als final deklarieren, um diese Eigenschaft sichtbar zu machen, aber das geht nicht, weil die Initialisierung nicht im Konstruktor, sondern "lazy" in der Methode getMyField() erfolgt. Semantisch ist das Feld aber final, sonst wäre die Verwendung des Racy-Single-Check-Idiom falsch.  Es könnte sonst passieren, das zwei Thread gleichzeitig " lazyField == 0 " sehen und beide nacheinander den Initialwert zuweisen. Wenn zwischendrin ein dritter Thread das Feld bereits verändert hätte, dann ginge diese Veränderung verloren.  Es ist also wichtig, dass der Inhalt des Feldes unveränderlich ist.

Racy-Single-Check mit einem Referenztyp

Hier ist ein Beispiel mit einer Referenz auf einen Integer vom Typ java.lang.Integer :

public class MyClass {
    private Integer lazyField = null;  // default value
    ...

    public Integer getMyField() {
        if (lazyField == null)
            lazyField = new Integer(10000);

        return lazyField;
    }

    ...
}

• Der Zugriff auf das fragliche Feld muss atomar sein . Das ist auch hier der Fall; die Ununterbrechbarkeit des Zugriffs auf Adressen, also Variablen von einem Referenztyp, ist in Java garantiert.
• Die Referenz lazyField ändert sich nach der Initialisierung nicht mehr.   Auch hier würde man das Feld gerne als final deklarieren, aber es geht wieder nicht wegen der "lazy" Initialisierung. Die final-Deklaration der Referenz bezöge sich ohnehin nur auf die Adresse des referenzierten Objekts und nicht auf das Objekt und seine Inhalte.  Ein unveränderliche Adresse reicht aber für das Racy-Single-Check-Idiom nicht aus; es muss eine dritte Voraussetzungen erfüllt sein.
• Das referenzierte Objekt und seine Inhalte ändern sich nach der Initialisierung nicht mehr. Wenn das Objekt veränderlich wäre, dann wäre die Verwendung des Racy-Single-Check-Idiom falsch, denn das Idiom lässt Mehrfach-Initialisierung zu.  Es könnte passieren, das zwei Thread gleichzeitig " lazyField == null " sehen und beide nacheinander den Initialwert zuweisen. Eine Veränderung des referenzierten Objekts, die zwischendrin ein dritter Thread vorgenommen hätte, ginge verloren.  Es ist also wichtig, dass nicht nur die Referenz, sondern auch das referenzierte Objekt unveränderlich ist.

Anforderungen an unveränderliche Typen

Ein unveränderlicher Typ muss auch für die Sichtbarkeit seiner Inhalte sorgen, das heißt, er muss sicher stellen, dass die unveränderlichen Inhalte des Objekts nach der Konstruktion allen benutzenden Threads sichtbar werden.  Denn was nützt es uns, wenn die Threads zwar die Adresse des Integers nach der Lazy-Initialisierung sehen, aber nicht die Inhalte des Integers?

Um für die Sichtbarkeit zu sorgen, braucht man bei der Implementierung eines unveränderlichen Typs die sogenannte "Initialization-Safety"-Garantie des Java Memory Modells.  Das ist eine Regel für die Sichtbarkeit der Inhalte der final-Felder von Objekten.

Sehen wir uns also die "Initialization-Safety"-Garantie des Java Memory Modells mal genauer an.
 

Speichereffekte im Zusammenhang mit  final-Feldern

Was heißt das genau?  Betrachten wir ein erstes einfaches Beispiel einer Klasse mit einem final-Feld:

public class Immutable {
  private final int field;
  public Immutable (int init) {
    field = init;
  }
  public String toString() {
    return "["+ field +"]";
  }
}

public class MyClass {
    private Immutable lazyField = null;  // default value
    ...

    public Immutable getMyField() {
        if (lazyField == null)
            lazyField = new Immutable(10000);

        return lazyField;
    }
    ...
}

public class Test {
  private static MyClass globalRef = new MyClass();

  public static void main(String[] args) {
    Runnable r = new Runnable() {
                 public void run() {
                   System.out.println(globalRef.getMyField().toString());
                 }
               };
    new Thread(r).start();
    new Thread(r).start();
  }
}

Wenn das Feld field in der Klasse Immutable nicht final wäre, dann könnte es in dieser Situation passieren, dass der zweite Thread das referenzierte Immutable -Objekt sieht und das Feld field in diesem Objekt entweder den Wert 0 oder 10000 hat.  Welchen der beiden Werte das Feld hat, ist undefiniert.  Es kann sogar passieren, dass der zweite Thread, wenn er mehrmals liest, erst den Wert 0 und später den Wert 10000 zu sehen bekommt.  Das sieht dann so aus, als sei das unveränderliche Objekt vom Typ Immutable gar nicht unveränderlich, weil sich sein Inhalt augenscheinlich ändert. Wie kann das sein?

Solche Effekte können bei fehlender final-Deklaration entstehen, weil es ohne die final-Deklaration keinerlei Garantien für die Sichtbarkeit des Feldes field gibt.

Sichtbarkeitsprobleme im Detail

Für den zweiten Thread sieht die Sache u.U. fundamental anders aus.  In der oben geschilderten Situation haben wir angenommen, dass das int-Feld in der Klasse Immutable nicht final ist und es daher keine Sichtbarkeitsgarantien gibt.  Dann ist undefiniert, welche von den Speichermodifikationen, die der erste Thread gemacht hat, überhaupt sichtbar wird. Wir haben mal angenommen, dass ein Teil sichtbar wird, nämlich die Adresse des konstruierten Immutable -Objekts, aber nicht dessen Inhalt.  Das ist ein denkbares Szenario; es kann auch passieren, dass der zweite Thread gar nichts zu sehen bekommen, auch nicht die Adresse des neu erzeugten Objekts.

Aber nehmen wir mal an, die Adresse wird sichtbar und der Rest nicht.  Dann sieht der zweite Thread zwar das neu erzeugte Immutable -Objekt, aber er sieht den Inhalt des Objekts in seinem Defaultzustand vor der Initialisierung der Felder, d.h. er sieht für das int-Feld den Wert 0.  Der erste Thread hat zwar das Immutable -Objekt ordnungsgemäß initialisiert, ehe dessen Adresse in der Referenzvariablen lazyField abgelegt wurde, und in dem int-Feld des Immutable -Objekts steht auch der beabsichtigte Initialwert 10000 drin, aber dieser Wert 10000 existiert nur im Cache des ersten Threads und nicht im Hauptspeicher (oder er steht im Hauptspeicher und der zweite Thread hat seinen Cache nicht aufgefrischt).  Wie auch immer die Konstellation genau sein mag, der Effekt ist, dass es für den zweiten Thread so aussieht, als sähe er das Objekt vor seiner Konstruktion.  Im weiteren zeitlichen Verlauf kann es dann noch passieren, dass der zweite Thread vielleicht noch einmal auf des Objekt schaut und in der Zwischenzeit Flushes und Refreshes erfolgt sind, so dass der Initialwert 10000 mittlerweile sichtbar geworden ist.  Dann sieht es für den zweiten Thread so aus, als habe sich das Immutable -Objekt von seinem Defaultzustand in seinen Initialzustand geändert.  Wie gesagt, es sieht nur so aus.  Dahinter stehen die mehr oder weniger zufällig passierenden Speichereffekte.

Weil "mehr oder weniger zufällig passierende Speichereffekte" keine verlässlich funktionierenden Programme ergeben, will man genau solche undefinierten Situationen nicht haben. Die beschriebenen Effekte sind in der Regel höchst unerwünscht und deshalb haben wir das int-Feld ganz bewußt als final deklariert.  Dann profitieren wir nämlich von der "Initialization Safety"-Garantie des Java Memory Modells.  Es garantiert, dass das final-Feld erst nach seiner Initialisierung sichtbar gemacht wird und niemals vorher.  Das heißt, wenn ein anderer Thread die Adresse des neu konstruierten Objekts zu sehen bekommt, dann sind garantiert alle final-Felder des neuen Objekts bereits in ihrer initialisierten Form sichtbar.

Für die Implementierung eines unveränderlichen Typs bedeutet es, dass grundsätzlich alle seine Felder als final deklariert sein müssen.

Unser Immutable -Typ im Beispiel ist korrekt implementiert: er hat keine verändernden Methoden und alle seine Felder sind als final deklariert.  Man kann ihn ohne Bedenken als Typ eines Felds verwenden, das mit dem Racy-Single-Check-Idiom initialisiert wird.  Das gilt aber, wie gesagt, nicht für alle Typen, die von sich behaupten, unveränderlich zu sein.  Wenn ein angeblich unveränderlicher Typ non-final-Felder hat, dann ist Vorsicht geboten, weil die oben ausführlich beschriebenen Sichtbarkeitsprobleme auftreten können.

Mögliche Missverständnisse

public class NoLongerImmutable {
  private final int finalField;
  private       int nonFinalField;
  public NoLongerImmutable(int init) {
    finalField = init;
    nonFinalField = init;
  }
  public String toString() {
    return "["+ finalField + "/" + nonFinalField +"]";
  }
  …
}

public class MyClass {
    private NoLongerImmutable lazyField = null;  // default value
    ...

    public NoLongerImmutable getMyField() {
        if (lazyField == null)
            lazyField = new NoLongerImmutable(10000);

        return lazyField;
    }
    ...
}

public class Test {
  private static MyClass globalRef = new MyClass();

  public static void main(String[] args) {
    Runnable r = new Runnable() {
                 public void run() {
                   System.out.println(globalRef.getMyField().toString());
                 }
               };
    new Thread(r).start();
    new Thread(r).start();
  }
}

Zusammenfassung

Die "Initialization Safety"-Garantie wird für die Implementierung von unveränderlichen Typen gebraucht: in einem unveränderlichen Typ müssen alle Felder als final deklariert sein, sonst kann es Sichtbarkeitsprobleme geben, beispielsweise wenn der unveränderliche Typ für eine lazy-Initialisierung mit dem Racy-Single-Check-Idiom verwendet wird.

Wir haben die gesamte Diskussion auf final-Felder von primitivem Typ beschränkt.  Wie ist das, wenn das final-Feld von einem Referenztyp ist?  Das sehen wir uns beim nächsten Mal an.
 

Literaturverweise

Die gesamte Serie über das Java Memory Model:

If you are interested to hear more about this and related topics you might want to check out the following seminar:

Seminar   Concurrent Java - An in-depth seminar covering all that is worth knowing about concurrent programming in Java, from basics such as synchronization over the Java 5.0 concurrency utilities to the intricacies of the Java Memory Model (JMM). 4 day seminar ( open enrollment and on-site)