Java Memory Model Details zu volatile-Variablen Java Magazin, Oktober 2008 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 diskutiert, dass Synchronisation mit Hilfe von Locks Performance kosten kann.  Um dies zu vermeiden, kann die Synchronisation unter Umständen durch andere Techniken ersetzt werden.  Eine Alternative zur Synchronisation ist die Verwendung von volatile-Variablen.  Deshalb wollen wir uns in diesem Beitrag näher mit volatile-Variablen befassen.
 

volatile als Alternative zur Synchronisation

public class Processor {
    private volatile boolean connectionPrepared = false;
    public void prepareConnection() {
        // ... open connection ...
        connectionPrepared = true;
    }
    public void start() throws InterruptedException {
        // ... various initializations ...
        while (!connectionPrepared )
            Thread.sleep(500);
        // ... start actual processing ...
    }
}

Das Lesen und Verändern des boolean Feldes ist nicht unterbrechbar.  Das garantiert die Sprachspezifikation mit der Regel, dass der Zugriff auf Variablen von primitiven Typ (außer long und double) und auf Referenzvariablen atomar ist.  Deshalb braucht man in dem Beispiel keine Synchronisation, um den Zugriff ununterbrechbar zu machen.

Wir haben an diesem Beispiel diskutiert, dass das boolean-Feld connectionPrepared aber als volatile deklariert werden muss, wenn auf Synchronisation verzichtet wird, damit die Modifikation, die der Initialisierungsthread macht, dem wartenden Thread sichtbar gemacht wird.  Diese Deklaration ist notwendig, weil das Java-Memory-Modell (JMM) nur unter bestimmten Bedingungen garantiert, dass Speichermodifikation anderen Threads sichtbar gemacht werden. Welche Bedingungen das sind, haben wir in einem Beitrag über das JMM (siehe / JMM2 /) diskutiert.  Unter anderem gibt es Sichtbarkeitgarantien für Synchronisation, aber auch für volatile-Variablen. Hier noch mal eine kurze Wiederholung:

Das Memory-Modell in Java ähnelt einer abstrakten SMP (= symmetric multi processing)-Maschine: die Threads laufen parallel und konzeptionell haben alle Threads Zugriff auf einen gemeinsamen Hauptspeicher (main memory), in dem die gemeinsam verwendeten Variablen abgelegt sind. Daneben hat jeder Thread einen eigenen lokalen Speicherbereich (cache), in den er Variablen hineinladen und lokal bearbeiten kann.  Das Zurückschreiben der lokalen Daten in den Hauptspeicher (flush) und das Hereinladen von Daten aus dem Hauptspeicher (refresh) muss nach den Regeln des JMM geschehen.

• Synchronisation. Der Erhalt eines Locks löst einen Refresh aus, das Freigeben des Locks löst einen Flush aus.  Alle Threads, die dasselbe Lock verwenden, durchlaufen die Sequenz der mit diesem Lock synchronisierten Anweisungen nicht parallel sondern nacheinander. Das heißt, es ist klar, dass zunächst ein Thread auf die gemeinsam verwendeten Daten zugreift und erst danach ein anderer.  Da beim Freigeben des Locks der eine Thread alle lokalen Daten in den Hauptspeicher zurück schreiben muss und der nächste Thread beim Erhalt des Locks seinen lokalen Arbeitsspeicher aus dem Hauptspeicher auffrischen muss, sieht der zweite Thread alle Modifikationen, die der erste Thread an den gemeinsam verwendeten Daten vorgenommen hat.

• Lese- und Schreibzugriff auf volatile-Variablen. Das Lesen einer volatile-Variablen löst einen Refresh aus, das Modifizieren einer volatile-Variablen löst einen Flush aus.  Das bedeutet, dass ein Thread, der den Inhalt einer volatile-Variablen liest, den Wert nicht aus seinem Arbeitsspeicher holen darf, sondern ihn aus dem Main Memory holen muss.  Dabei muss er nicht nur den Inhalt der betreffenden volatile-Variablen holen, sondern er muss seinen gesamten Arbeitsspeicher auffrischen.  Auf diese Weise sieht er alle Modifikation an gemeinsam verwendeten Variablen, die zuvor ein anderer Thread gemacht hat, der auf dieselbe volatile-Variablen vorher schreibend zugegriffen hat. Denn beim schreibenden Zugriff muss der andere Thread seinen gesamten Arbeitspeicher in den Hauptspeicher zurückgeschrieben haben.

Mißverständnis

public class IntStack {  // falsch; nicht nachmachen !!!
  // attributes:
  private int[] array;
  private int cnt = 0;

  // constructor:
  public int_stack(int capacity) { array = new int[capacity]; }

  // methods:
  public synchronized void push(int elm)  { array[cnt++] = elm; }
  public synchronized int pop()           { return(array[--cnt]); }
  public              int size()          { return cnt; }
}

Wie ist das aber nun mit der Sichtbarkeit der Modifikationen am cnt-Feld?  Das cnt-Feld ist nicht volatile, aber es sind alle modifzierenden Zugriffe auf das Feld synchronisiert.  Da Synchronisation Flushes auslöst, werden die Änderungen am cnt-Feld sichtbar, die in den Methoden push und pop gemacht wurden.  Also ist die Implementierung in Ordnung - so lautet zumindest ein gelegentlich anzutreffendes Mißverständnis.  Leider ist es nicht ganz so.

Es genügt nicht, dass die Modifikationen am cnt-Feld wegen der Synchronisation der Methoden push und pop gemäß JMM-Regeln in den Hauptspeicher geflusht werden.  Wenn die size-Methode unsynchronisiert auf das cnt-Feld zugreift, dann ist nicht garantiert, dass vor dem Lesezugriff ein Refresh gemacht wurde.  Es kann also passieren, dass ein Thread durch zahlreiche pop-Aufrufe das cnt-Feld inkrementiert und ein anderer Thread, der periodisch mit der size-Methode das cnt-Feld abfragt, diese Änderung nicht zu sehen bekommt, weil der cnt-Wert stets aus dem Cache des Threads und nicht aus dem Hauptspeicher geholt wird.

Es genügt also bereits ein einziger Zugriff ohne Speichergarantien auf eine Variable und die Sichtbarkeit ist nicht mehr gewährleistet.  In dem Beispiel muss daher das cnt-Feld als volatile deklariert werden.

public class IntStack {  // jetzt ist es in Ordnung
  // attributes:
  private int[] array;
  private volatile int cnt = 0;

  // constructor:
  public int_stack(int capacity) { array = new int[capacity]; }

  // methods:
  public synchronized void push(int elm)  { array[cnt++] = elm; }
  public synchronized int pop()           { return(array[--cnt]); }
  public              int size()          { return cnt; }
}

Kosten von volatile

So kann zum Beispiel ein sehr häufiger Zugriff auf eine volatile-Variable, zum Beispiel in einer Schleife, in Summe teurer sein, als die einmalige Synchronisation der gesamten Schleife, weil jeder einzelen Zugriff auf die volatile-Variable einen Refresh oder Flush auslöst, die Synchronisation aber nur jeweils einen Refresh und Flush. Wo jeweils der Trade-off ist, muss man im Einzelfall mit einer Benchmark-Messung bestimmen.  Wir wollen an dieser Stelle nur darauf hinweisen, dass man volatile auch aus Versehen zu ungünstig verwenden kann, dass sich u.U. negative Performance-Effekte einstellen.

Natürlich ist die Benutzung von volatile und Synchronisation mit Hilfe von Locks nicht in allen Belangen gleichwertig. Die Locks sind zusammen mit Conditions in einen Framework eingebettet, der auch komplexere Synchronisation mit Hilfe von wait()/await() und notify()/signal() erlaubt.  Bei volatile ist das nicht so.  Hier bleibt nur das mehrmalige Versuchen (Pollen), bis sich die Situation eingestellt hat, auf die man wartet.  Das muss nicht immer zu schlechten Lösungen führen. Dies kann man an dem ersten Beispiel in diesem Artikel sehen.  Eine Implementierung des Latch-Pattern auf Basis von volatile, bei dem der Startthread wartet, bis die Kommunikationsfunktionalität initialisiert ist, macht durchaus Sinn.  In anderen Situationen können sich aber ernste Nachteile aus dem erhöhten CPU-Verbrauch (auf Grund des Pollens) und der lose gekoppelten Synchronisation beider Threads ergeben. In diesem Sinne muss man auch einige Beispiele in diesem Artikel sehen. Sie haben einen didaktischen, theoretischen Hintergrund: um an möglichst einfachen Beispielen die Speichereffekte von volatile zu diskutieren. Deshalb wrden wir in unserem nächsten Artikel das Thema noch mal von der praktischen Seite am Beispiel des Double-Check-Idioms aufrollen.
 

Speichereffekte von volatile auf andere Variablen

class FutureResult {   // korrekt, aber nicht unbedingt empfehlenswert
  private volatile boolean ready = false;
  private Object data = null;

  public Object getResult() {
    if (ready);
    return data;
  }
  public boolean isReady() {
    return ready;
  }
  // only one thread may ever call putResult()
  public void putResult(Object o) {
    data = o;
    ready = true;
  }
}

Auf Synchronisation wird komplett verzichtet.  Für die Methoden getResult und isReady geht das, weil sie lediglich atomare Operationen ausführen und deshalb nicht unterbrechbar sind.  Die Method putResult braucht keine Synchronisation, weil unterstellt wird, dass nur ein einziger Thread diese Methode einmal aufruft.  Wegen dieser Benutzungskonvention kann es keine konkurrierenden putResult-Aufrufe geben.  Die konkurrierenden Aufrufe von getResult und isReady stellen auch kein Problem dar. Wenn eine dieser Methoden mitten in der putResult-Methode auf die Felder ready und/oder data zugreift, dann liefert isReady schlimmstenfalls noch false zurück, obwohl das Resultat bereits im Feld data abgelegt ist.  Diese vorübergehende Inkonsistenz der Daten ist aber kein Problem, weil der abfragende Thread dann beim nächsten Aufruf von isReady die konsistente Information erhält.

Da auf Synchronisation verzichtet wurde, haben wir unsynchronisierte Zugriffe auf die beiden Felder ready und data und wir müssen für die Sichtbarkeit der Modifikationen an diesen Feldern sorgen.  Das wird getan, indem das boolean-Feld ready als volatile deklariert ist.  Das Referenzfeld data ist hingegen nicht volatile.  Ist das korrekt oder müssen beide Felder volatile sein?

Wenn man die Sichtbarkeitsregeln für volatile-Variablen genau ansieht, stellt man fest, dass es in der Tat genügt, wenn das ready-Feld volatile ist.  Der schreibende Zugriff auf ready in der Methode putResult löst nämlich einen Flush aus.  Dabei wird nicht nur der Inhalt von ready geflusht, sondern es werden alle Speichermodifikationen sichtbar, die der Thread bis dahin gemacht hat, also auch die Modifikation an der Referenzvariablen data.  Die seltsame if-Abfrage in der Methode getResult mit dem leeren Statement im true-Fall dient einem ganz ähnlichen Zweck und ist keineswegs überflüssig.  Der Lesezugriff auf die volatile-Variable ready löst einen Refresh aus, der nicht nur den aktuellen Inhalt von ready aus dem Hauptspeicher beschafft, sondern auch alle anderen Variablen auffrischt, auf die der Thread zugreifen wird.  Damit wird auch der aktuelle Inhalt der Referenzvariablen data dem lesenden Thread sichtbar.

Nun ist das ganze Beispiel etwas seltsam, weil es um maximale Optimierung bemüht ist.  Der Verzicht auf die Synchronisation ist nur wegen der Benutzungskonvention möglich und dann wird auch noch versucht, mit möglichst wenig volatile-Variablen auszukommen.  Im Hinblick auf die Optimierung ist es gut, in Hinblick auf die Verständlichkeit des Codes muss man sich allerdings fragen, ob es hier nicht sinnvoller wäre, beide Felder als volatile zu erklären.  Der Verzicht auf die volatile-Deklaration für die Referenzvarable data führt schließlich zu einem subtilen und damit recht fragilen Code, der bei geringfügigen Änderungen bereits inkorrekt wird.  Der Leser des Source-Code muss folgende Aspekte verstanden haben:

• Die Reihenfolge der Anweisungen in der Methode putResult ist wichtig, denn der Zugriff auf das volatile-Feld muss ganz am Ende nach allen anderen Modifikationen geschehen, sonst werden die anderen Modifikationen nicht sichtbar.
• Der doch recht künstlich anmutende Lesezugriff auf das volatile-Feld ready in der Method getResult ist ebenfalls wichtig, weil sonst die Sichtbarkeit des anderen non-volatile Feldes fehlen würde.

class FutureResult {   // korrekt
  private volatile boolean ready = false;
  private volatile Object data = null;

  public Object getResult() {
    return data;
  }
  public boolean isReady() {
    return ready;
  }
  // only one thread may ever call putResult()
  public void putResult(Object o) {
    data = o;
    ready = true;
  }
}

volatile-Referenzvariablen

public class Pair {
     private Object first;
     private Object second;

     public void addFirst(Object o) {
            first = o;
     }
     public void addSecond(Object o) {
            second = o;
     }
     public Object[] toArray() {
            return new Object[] {first,second};
     }
}
public class FutureResult {
    private volatile Pair data = null;

    public Object[] getResult() {
        return (data==null)?null:data.toArray();
    }
    public void isReady() [
        return data != null;
    }
    // only one thread may ever call putResult()
    public void putResult(Object o1,Object o2) {
        Pair tmp = new Pair();
        tmp.addFirst(o1);
        tmp.addSecond(o2);
        data = tmp;
    }
}

Die Methode putResult erzeugt und füllt ein temporäres Pair-Objekt und weist danach der volatile-Variablen data die Adresse dieses temporären Objekts zu.  Diese Adressezuweisung löst den Flush aus und dabei werden alle ggf. im Cache des Threads gemachten Speichermodifikationen in den Hauptspeicher geschrieben.  Damit werden garantiert auch die Inhalte des referenzierten Pair-Objekts sichtbar.  Die Methoden getResult und isReady müssen lesend auf die volatile-Variablen data zu, ehe sie den Inhalt des referenzierten Pair-Objekts anschauen können.  Das Lesen der Adresse löst den Refresh aus, der auch die Inhalte des referenzierten Pair-Objekts sichtbar macht.

Wichtig ist hierbei, dass die Methode putResult die Modifikation der Adresse nach der Modifikation der Inhalte des referenzierten Objekts macht.  Folgende Implementierung wäre daher falsch:

    public void putResult(Object o1,Object o2) {
        data = new Pair();
        data.addFirst(o1);
        data.addSecond(o2);
    }

Damit die putResult() Methode von oben korrekt funktioniert, kann die Pair Klasse so geändert werde, dass die beiden Felder first und second auch volatile sind:

public class Pair {
     private volatile Object first;
     private volatile Object second;

     public void addFirst(Object o) {
            first = o;
     }
     public void addSecond(Object o) {
            second = o;
     }
     public Object[] toArray() {
            return new Object[] {first,second};
     }
}

Der Ansatz, weitere geschachtelt enthaltene Felder volatile zu machen, hat natürlich seine Limitationen: Wenn wir keinen Zugriff auf den Sourcecode der Klasse (in unserem Fall Pair) haben, ist dies nicht möglich.  Ein anderes Beispiel sind Java Arrays. Hier ist es auch nicht möglich, die Elemente des Arrays explizit volatile zu machen., sodass die korrekte Implementierung unseres Beispiels mit einem Object-Array so aussieht:

public class FutureResult {
    private volatile Object[] data = null;

    public Object[] getResult() {
        return data;
    }
    public void isReady() [
        return data != null;
    }
    // only one thread may ever call putResult()
    public void putResult(Object o1,Object o2) {
        Object[] tmp = new Object[2];
        tmp[0] = o1;
        tmp[1] = o2;
        data = tmp;
    }
}

Zusammenfassung

Literaturverweise und weitere Informationsquellen

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)