Java Memory Model Atomic Scalars Java Magazin, August 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 Beiträge in dieser Kolumne [ JMM4 ] über die Performance-Vorzüge und Speichereffekte von volatile im Kontext von konkurrierenden Threads geschrieben. Leider hat volatile gewisse Einschränkungen.  So ist es beispielsweise nicht möglich, eine atomare Read-Modify-Write-Sequenz auf einer volatile Variablen auszuführen; es sind nur die einzelnen Lese- und Schreibzugriffe atomar, nicht aber die ganze Sequenz.  Als logische Verallgemeinerung von volatile Variablen  gibt es seit Java 5.0 atomare Variablen, die ununterbrechbare Read-Modify-Write-Sequenzen unterstützen und ansonsten dieselben Vorzüge und Speichereffekte wie volatile haben.   In diesem Beitrag sehen wir uns die atomaren skalaren Variablen an.

Es gibt immer mal wieder Situationen, in denen man die Thread-Synchronisation mit Hilfe von Locks durch die Verwendung von volatile-Variablen ersetzt möchte, um die Performance zu verbessern.  Das ist möglich, wenn der Zugriff auf eine gemeinsam verwendete Variable sowieso schon ununterbrechbar ist, wie zum Beispiel beim lesenden oder schreibenden Zugriff auf primitive Typen (außer long und double) und Referenzen.  In solchen Fällen wird die Synchronisation nicht gebraucht, um den Zugriff auf die Variable ununterbrechbar zu machen, sondern nur noch, um die Variable sichtbar zu machen.  Da es seit Java 5.0 aber Sichtbarkeitsgarantien für volatile-Variablen gibt, kann man hier auf die Synchronisation verzichten und stattdessen volatile verwenden. Mit long und double funktioniert die Lösung auch.  Im Unterschied zu den übrigen primitiven Typen ist der Zugriff auf non-volatile-Variablen vom Typ long und double unterbrechbar, aber wenn eine Variablen vom Typ long und double als volatile erklärt ist, dann ist der Zugriff atomar. Diese Ununterbrechbarkeit ist bei long und double also ein zusätzlicher Effekt von volatile, den man bei dieser Situation ausnutzt.

Ein threadsicherer Zähler

public class VolatileCounter {  // Vorsicht: falsch !!!
  private volatile int value;
  public int getValue()  { return   value; }
  public int increment() { return ++value; }
  public int decrement() { return --value; }
}

Man muss also die Methoden increment() und decrement() synchronisieren, damit sie ununterbrechbar sind.  Lediglich die Methode getValue() kann ohne Synchronisation auskommen.  Dann sähe die Counter-Klasse so aus:

public class SynchronizedCounter {  // korrekt, aber nicht optimal
  private volatile int value;
  public int getValue()  { return   value; }
  public synchronized int increment() { return ++value; }
  public synchronized int decrement() { return --value; }
}

CAS - Compare-and-Swap

Leider war es bis Java 5.0 nicht möglich, diese Funktionalität von Java einfach auszunutzen.  Seit Java 5.0 gibt es im Package java.util.concurrent.atomic verschiedene Klassen, die basierend auf CAS-Operationen ununterbrechbare Read-Modify-Write-Sequenzen anbieten.  Dazu gehören Typen, wie AtomicInteger, AtomicLong und AtomicBoolean.

Eine Compare-and-Swap-Operation hat 3 Operanden:

• eine Speicherstelle
• den erwarteten alten Wert an dieser Speicherstelle
• einen neuen Wert für die Speicherstelle

Damit kann man ohne Synchronisation Modifikationen an Variablen vornehmen, die von mehreren Thread gemeinsam verwendet werden.  Das Vorgehen ist dabei folgendes: Man verfolgt eine optimistische Strategie und versucht einfach mal, die Variable zu ändern.  Wenn kein anderer Thread konkurrierend zugreift, dann klappt die CAS-Operation.  Wenn sie scheitert, dann gab es wohl konkurrierende Zugriffe und ein anderer Thread war schneller.  In diesem Fall wird der Änderungsversuch solange wiederholt, bis er erfolgreich ist.

Solche atomaren CAS-Operationen haben den Vorteil, dass sie bei wenig Konkurrenz um den Variablenzugriff performanter sind als synchronisierte Zugriffe, weil der gesamte Synchronisationsaufwand wegfällt.  Bei sehr viel Konkurrenz kann unter Umständen die Synchronisation wieder günstiger sein, weil die CAS-Zugriffe dann mit hoher Wahrscheinlicheit scheitern und wiederholt werden müssen.  Das kostet dann zusätzliche CPU-Zeit.  Atomare Operationen haben aber gegenüber Synchronisation stets den Vorteil, dass zumindest ein Thread immer erfolgreich sind wird.  So etwas wie Deadlocks, wo kein einziger Thread mehr arbeitet, kann mit atomaren Operationen nicht vorkommen.

Neben der Ununterbrechbarkeit haben die Zugriffe auf atomare Variablen dieselben Speichereffekte wie die Zugriffe auf volatile-Variablen.  Deshalb werden die atomaren Variable auch als logische Verallgemeinerung von volatile angesehen.

Ein threadsicherer Zähler unter Verwendung von atomaren Variablen

public class AtomicCounter {  // korrekt und optimiert
  private AtomicInteger value = new AtomicInteger();
  public int getValue() { return value.get(); }
  public int increment() {
   int oldValue = value.get();
   while (!value. compareAndSet (oldValue, oldValue + 1))
     oldValue = value.get();
   return oldValue + 1;
  }
  public int decrement() {
   int oldValue = value.get();
   while (!value. compareAndSet (oldValue, oldValue - 1))
     oldValue = value.get();
   return oldValue - 1;
  }
}

Das Inkrementieren erfolgt nun so:  zunächst wird der aktuelle Wert des Integers gelesen, um den neuen Wert oldValue+1 zu berechnen.  Dann soll die Modifikation gemacht werden.  Zwischen Lesen und Modifizieren ist der Thread unterbrechbar; es könnte also ein anderer Thread den Integer in der Zwischenzeit modifiziert haben.  Deshalb wird die atomare Operation compareAndSet() aufgerufen.  Sie prüft, ob der zuvor gelesene Wert noch aktuell ist.  Wenn ja, dann ist die Modifikation erfolgreich und es kommt true zurück.  Wenn nein, dann kommt false zurück und der ganze Vorgang von "Wert auslesen", "neuen Wert berechnen" und compareAndSet() wird wiederholt.  Da compareAndSet() mit Lesen und Schreiben der Variablen verbunden ist, wird sowohl ein Refresh als auch ein Flush ausgelöst.  Das Dekrementieren funktioniert analog.

Typisch für die Verwendung von atomaren Variablen ist die Schleife, in der die Operation solange wiederholt wird, bis sie erfolgreich ist.  Insgesamt sieht die Counter-Implementierung mit Hilfe von atomaren Variablen deutlich komplizierter aus als die einfache Implementierung mit Synchronisation.  Die Klasse AtomicInteger hat zwar spezielle incrementAndGet- und getAndIncrement-Methoden, die dem Postfix- und Prefix-Inkrement entsprechen; analog fürs Dekrementieren.  Deutlich einfacher sieht die Lösung damit aber auch nicht aus.  Zum anderen wollten wir aus didaktischen Gründen hier auch das typische Vorgehen bei der Benutzung von atomaren Variablen zeigen.

Zusammenfassung

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)