Java Memory Model Die Initialisation-Safety-Garantie für final-Felder von einem Referenztyp Java Magazin, April 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 im letzten Beitrag [ JMM6 ] die Initialisation-Safety-Garantien des Java Memory Modells für final-Felder besprochen.  Dabei geht es um die Garantie, dass alle final-Felder eines Objekts stets in ihrem Zustand nach der Konstruktion und nie in ihrem Defaultzustand vor der Konstruktion sichtbar werden.  Wir haben dabei ein final-Feld vom Typ int, also einem primitiven Typ, betrachtet.  Wie sehen die Garantien für final-Felder von einem Referenztyp aus?  Werden auch die referenzierten Objekte sichtbar oder nur die Referenz selbst? Das wollen wir uns in diesem Beitrag ansehen.

Ausgangspunkt unserer Diskussion war die Lazy-Initialisierung eines Feldes mit Hilfe des Racy-Single-Check-Idioms (siehe [ JMM5 ]).  Bei diesem Idiom wird weder Synchronisation noch volatile genutzt.  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 hier der Fall, weil das Feld von einem Referenztyp ist.
• Die Referenz lazyField ändert sich nach der Initialisierung nicht mehr.  Um das sicherzustellen, würde man das Feld gerne als final deklarieren, aber es geht 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. Deshalb 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

Bei der "Initialization Safety"-Garantie des Java Memory Modells geht es darum, dass stets die Initialwerte von final-Feldern und niemals die Defaultwerte sichtbar sind.  Wenn also ein Thread ein Objekt mit final-Feldern zu sehen bekommt, weil er die Adresse des Objekts sehen kann, dann sieht er die final-Felder des Objekts stets im Initialzustand nach der Konstruktion und nie im Defaultzustand vor der Konstruktion.

Wir haben dazu ein Beispiel mit einer Klasse mit einem final-Feld betrachtet:

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();
  }
}

Da das int-Feld field in der Klasse Immutable als final deklariert ist, garantiert die Initialisation-Safety-Garantie, dass der zweite Thread das Immutable-Objekt in seinem fertig initialisierten Zustand zu sehen bekommt.  Der Wert des int-Feld field ist 10000 und nicht etwa 0, wie es bei fehlender final-Deklaration der Fall sein könnte.
 

Sichtbarkeitsgarantieren für abhängige Objekte

public class Immutable {
  private final int[] finalArrayRef;
  public Immutable(int start, int size) {
    finalArrayRef = new int[size];
    for (int i=0;i<size;i++)
       finalArrayRef[i] = start+i;
  }
  public String toString() {
    return "["+ Arrays.toString(finalArrayRef) +"]";
  }
}

Glücklicherweise gibt das Java Memory Modell in der Tat derartige Garantien für die Array-Elemente. Die Garantie für final-Felder bezieht sich nämlich nicht nur auf die final-Felder selbst. Für final-Felder, die von einem Referenztyp sind, ist garantiert, dass die Referenz und alle "abhängigen" Objekte sichtbar gemacht werden.

Die "abhängigen" Objekte sind jene, die von einem final-Feld aus per Referenz erreichbar sind, und alle Objekte, die wiederum von dort aus per Referenz erreichbar sind.  Gemeint ist also die gesamte transitive Hülle aller erreichbaren Objekte.  Das würde in unserem Beispiel alle Array-Elemente einschließen.  In dem SMP-Modell für das Java Memory, das wir in [ JMM2 ] beschrieben haben, kann man es sich so vorstellen, als ob am Ende der Konstruktion eines Objekts mit final-Feldern ein partieller Flush ausgelöst würde, bei dem die final-Felder des Objekts und alle "abhängigen" Objekte in den Hauptspeicher zurückgeschrieben werden.  In jedem Falle ist garaniert, dass alle final-Felder eines Objekts und alle von diesen final-Feldern aus erreichbaren Objekte anderen Thread sichtbar gemacht sind, ehe die Adresse des Objekts sichtbar wird und die anderen Threads auf die final-Felder zugreifen können.

Unser Immutable-Typ mit dem Array wäre also korrekt implementiert: er hat keine verändernden Methoden, alle seine Felder sind als final deklariert und die Initialisation-Safety-Garantie sorgt dafür, dass auch die Array-Elemente sichtbar werden.  Man kann ihn ohne Bedenken als Typ eines Felds verwenden, das mit dem Racy-Single-Check-Idiom initialisiert wird.

Wie ist das nun, wenn der unveränderliche Typ eine Referenz auf ein Array mit Referenzen (statt primitiven Elementen) enthält, also kein int[], sondern ein Integer[]? Die Initialisation-Safety-Garantie sorgt dann dafür, dass auch die von den Array-Elementen referenzierten Objekte und deren Inhalte sichtbar werden.  Damit der äußere Typ Immutable unververänderlich ist, müssen die Array-Elemente natürlich wiederum von einem korrekt implementierten unveränderlichen Typ (wie z.B. Integer oder String) sein.

Was wir hier am Beispiel einer final-Referenz auf ein Array erläutert haben, gilt analog für final-Referenzen auf Objekte. Die Initialisation-Safety-Garantie sorgt dafür, dass die gesamte transitive Hülle aller erreichbaren Objekte am Ende der Konstruktion sichtbar wird.
 

Mögliche Mißverständnisse

Die Unveränderbarkeit des Arrays ist aber durch nichts gewährleistet, weil die final-Deklaration der Array-Referenz nur sagt, dass die Adresse des Arrays konstant ist, nicht aber der Inhalt des Array selbst.  Es wäre also prinzipiell  möglich, dass sich das Array und seine Elemente ändern. Für die Sichtbarkeit dieser späteren Änderungen gibt das Java Memory Modell keine Garantien.  Sehen wir uns das im Beispiel mal an:

public class NoLongerImmutable {
  private final int[] finalArrayRef;
  public NoLongerImmutable(int start, int size) {
    finalArrayRef = new int[size];
    for (int i=0;i<size;i++)
       finalArrayRef[i] = start+i;
  }
  public String toString() {
    return "["+ Arrays.toString(finalArrayRef) +"]";
  }
  public void update(int idx, int val) {
    finalArrayRef[idx] = val;
  }
}

Unterschiede zu volatile

final Variablen vs. final Felder

Schauen wir uns zur Illustration einen Fall an, in dem zwar final verwendet wird, seine Verwendung aber nichts mit Initialization Safety zu tun hat.

public class ActiveObject{
  public ActiveObject(long times) throws InterruptedException {
    final long[] argumentAndResult = new long[2];
    argumentAndResult[0] = times;

    Runnable r = new Runnable() {
      public void run() {
        long start = System.nanoTime();
        for (int i=0;i<argumentAndResult[0];i++)
           System.out.print("*");
        argumentAndResult[1] = System.nanoTime()-start;
      }
    };
    Thread t = new Thread(r,"printer");
    t.start();
    t.join();
    System.out.println(argumentAndResult[1]);
  }
}

Hier hat die Verwendung von final überhaupt nichts mit den oben besprochenen Speichereffekten für final-Felder zu tun, denn hier brauchen wir gar keine Garantien im Zusammenhang mit final-Variablen.

Die benötigten Speichererffekte werden hier durch Thread-Start und Thread-Ende geliefert, nicht durch die final-Deklaration der Array-Referenz.  Der Start des printer-Threads löst einen Flush im main-Thread und einen Refresh im printer-Thread aus.  Das heißt, der neu gestartete printer-Thread kann sehen, was der ihn startende main-Thread gemacht hat.  Analog beim Thread-Ende: der main-Thread wartet mit Thread.join() auf das Ende des printer-Threads und kann dann alles sehen, was der printer-Thread gemacht hat.

Und eine letzter Hinweis auf mögliche Mißverständnisse:
Für die Thread-Ende-Garantie ist übrigens wichtig, dass sich der eine Thread über das Ende des anderen Threads aktiv informiert hat (per join() oder isAlive()).  Wenn der printer-Thread nur zufällig schon gerade fertig ist, dann ist nicht garantiert, dass der main-Thread sieht, was der printer-Thread gemacht hat, weil der Refresh im main-Thread erst durch join() oder isAlive() ausgelöst wird.

Zusammenfassung

Diese Garantie gibt es nur für final-Felder und nicht für final-Variablen.  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 und alle abhängigen Objekte müssen ihrerseits unveränderlich sein.

Im nächsten Beitrag sehen wir uns, was man trotz Verwendung von final bei der Implementierung von unveränderlichen Typen falsch machen kann. Die "Initialization Safety"-Garantie gilt nämlich nur, wenn der sogenannte Object Escape verhindert wird. Das schauen wir uns im nächsten Beitrag genauer 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)