Das Java Memory Model: Überblick und Ausblick auf Java 9

Von Vadym Kazulkin und Rodion Alukhanov

Passend zum baldigen Release von Java 9 wird es Zeit, sich noch einmal intensiv mit dem Java Memory Model auseinanderzusetzen, dessen Spezifikation zu den kompliziertesten im Java-Umfeld gehört. In diesem shortcut nehmen Rodion Alukhanov und Vadym Kazulkin das JMM genau unter die Lupe, betrachten unter anderem Hardware-Memory-Module, das Jopen JDK Java Concurrencty Stress Tests Tool und wagen einen Ausblick auf die Zukunft des JMM mit Java 9.

• Sprache: Deutsch
• Herausgeber: entwickler.press
• Erscheinungsdatum: 2. Aug. 2017
• ISBN: 9783868027617

Buchvorschau

GmbH

1 Hardware-Memory-Modelle reloaded

Die Spezifikation des Java Memory Model gehört zu der kompliziertesten im Java-Umfeld; deren Verständnis ist aber in Zeiten von Mehrkernprozessoren extrem wichtig, um Java-Applikationen zu schreiben, die Nebenläufigkeit korrekt unterstützen.

Mit Java 9 dürfte ein Update des Java Memory Models zu erwarten sein [1]. Zu diesem Anlass haben wir uns entschieden, das Thema zu beleuchten. Im ersten Teil der Artikelserie geben wir einen kurzen Überblick über die verschiedenen Hardware-Memory-Modelle, was auf den ersten Blick ungewöhnlich erscheint. Wieso ist uns das wichtig? Das Versprechen, das uns Java gibt „Write once – run everywhere", klingt zwar einfach, ist aber in der Praxis nicht trivial umsetzbar, denn viele Hardware-Memory-Modelle haben ihre eigenen Besonderheiten. Deren Komplexität will die Spezifikation des Java Memory Model [2] vor uns nur verstecken, indem sie eine Abstraktionsschicht definiert. Viele würden das Java Memory Model als sehr komplex erachten – ist es auch. Dafür gibt es Gründe, die wir in dieser Artikelserie näher beleuchten wollen. Zuerst schauen wir uns ein einfaches Beispiel aus Listing 1.1 an.

public class MyClass {

  int x, y;

  public void executeOnCPU1() {

    x = 1;

    x = 2;

    y = 1;

    x = 3;

  }

  public void executeOnCPU2() {

    System.out.println(x: +x+ y: +y);

  }

}

Listing 1.1: Quizbeispiel

Wir sehen in der Klasse zwei Methoden und gehen davon aus, dass executeOnCPU1 und executeOnCPU2 parallel von unterschiedlichen Threads auf unterschiedlichen Prozessoren ausgeführt werden. Da keinerlei Synchronisation im Code stattfindet, stellen wir nun die Frage: Wenn in der Ausgabe der Methode executeOnCPU2 y=1 erscheint, welche Werte von x könnten in der gleichen Zeile ausgegeben werden? Bei Werten wie x=2 und x=3 sollte jedem klar sein, was das zu erwartende Ergebnis ist. Aber sind auch die Werte x=0 oder x=1 möglich? Wenn wir aber die Fragestellung präzisieren und ergänzen, dass das Programm auf einem x86-Prozessor läuft, ändert sich dadurch bei der Antwort irgendetwas? Und wenn wir es auf dem Android-Gerät mit dem ARMv7 laufen lassen? Gibt es Tools, mit denen wir das verlässlich testen können? Wir haben schon sehr viele Fragen, die wir alle im Rahmen dieses shortcuts beantworten werden. Wir fangen aber mit etwas Theorie an.

L1, L2, L3: die Memory-Hierarchie

Abbildung 1.1 ist eine einfache Darstellung der Memory-Hierarchie. Wir sehen, dass jeder Prozessor eigene L1-(First-Level-) und L2-(Second-Level-)Caches besitzt. Es gibt noch einen optionalen prozessorübergreifenden L3-Cache. Der L1-Cache besteht häufig aus Instruction- und Data-Caches.

Abbildung 1.1: Memory-Hierarchie

In den Caches werden die Informationen gespeichert, die der Prozessor häufig und in naher Zukunft für seine Berechnungen benötigt. Bei der Suche nach Information geht der Prozessor die Caches in der Reihenfolge L1, L2, L3 nacheinander durch. Falls in keinem der Caches die vom Prozessor gesuchte Information zu finden ist (Cache miss), findet ein Zugriff auf den Hauptspeicher statt. Generell gilt: Je näher der Cache am Prozessor ist, desto kleiner ist er. Wie groß die Caches tatsächlich sind, kann man