Java Memory Model (JSR-133)

Transkript

1 Seminarbericht von Simon Müller, 6Ie Fachhochschule Aargau Departement Technik Studiengang Informatik Betreuender Dozent: Prof. Dr. D. Gruntz Windisch, 10. Juni 2005

2 Abstract Java Memory Model (JSR-133) This report highlights the differences and improvements between the old Java Memory Model and the revised model which is also known as JSR-133. Not only was the old memory model specification written in an incomprehensible and complicated way, but also it contained some serious flaws. The JSR-133 specification corrects these problems with an adjusted writing style and redefinitions of faulty parts. With academic explanations as well as with practical examples, the reader of this document gets sensitized in writing multithreading applications. An example thereof is the double-checked locking problem which is discussed in detail in the last chapter. After reading this report, the reader is able to identify the problems of the old memory model and knows about the corrections made. Moreover, he or she gets a better understanding of the hidden procedures performed internally, according to the memory model specification, which helps to write more reliable multithreading applications. Simon Müller 10. Juni 2005 Seite 1

3 Inhaltsverzeichnis Java Memory Model (JSR-133) Einleitung Was ist ein Speichermodell (Memory Model)? Das ursprüngliche Java Memory Model und seine Mängel JSR-133: Java Memory Model and Thread Specification Das Java Memory Model im Detail Der final Modifier Der volatile Modifier Multithreaded Singleton Pattern / Double-checked locking... 8 Schlusswort Bibliographie L1. Literatur L2. Internet Simon Müller 10. Juni 2005 Seite 2

4 Einleitung Der vorliegende Seminarbericht bildet den abschliessenden Teil der Enterprise Computing Seminarreihe Java 5: Taming the Tiger. Abgesehen vom ersten Kapitel ist dieser Bericht nicht für Java Einsteiger geeignet, d.h. die Erfahrung mit Multithreading-Programmierung wird vorausgesetzt. So müssen die Schlüsselwörter synchronized, volatile und final in Zusammenhang mit Java bekannt sein um die Arbeit zu verstehen und von den Erkenntnissen profitieren zu können. Es ist allgemein bekannt, dass die Entwicklung von Multithreading-Applikationen in die Königsklasse der Programmierung gehört. Obwohl viele Programmierer und Programmiererinnen das Gefühl haben, die Konzepte und Funktionsweisen der Synchronisationsmechanismen verstanden zu haben, liegen viele Irrtümer vor. Diesen Eindruck bekommt man beim Durchstöbern von Java Foren relativ schnell vermittelt. Vor vier Jahren hat sich eine Expertengruppe [13] gebildet, um dieses Problem in den Griff zu bekommen. Die Resultate werden in diesem Seminarbericht zusammengefasst dargestellt. Bevor in die Details des Java Memory Models eingetaucht werden kann muss einleitend geklärt werden, was ein Speichermodell ist und was dessen Aufgaben sind. Das erste Kapitel befasst sich mit dieser Frage und beantwortet diese in einer definitionsähnlichen Art und Weise. Im Kapitel 2 werden die Probleme des alten Java Memory Models aufgezeigt. Dadurch wird klar, dass die Java Language Specification [5] einige Mängel aufweist, die behoben werden müssen. Dem aufmerksamen Leser wird auffallen, dass einige Probleme angesprochen, jedoch keine Lösungen vorgeschlagen werden. Aber keine Panik, das anknüpfende Kapitel holt dies nach. Das Kapitel 3 bildet den eigentlichen Kern dieses Seminarberichts und ist so gesehen in zwei Hälften geteilt. Die erste Hälfte beschreibt in Textform die Veränderungen gegenüber dem ursprünglichen Java Memory Model. In der zweiten Hälfte werden auf die angesprochenen Problemfälle des ursprünglichen Speichermodells eingegangen, mit dem neuen Modell verglichen und mit Beispielen veranschaulicht. Der abschliessende Rahmen dieser Arbeit bildet das Kapitel zum double-checked locking -Problem. Dieses Pattern wurde in den vergangenen Jahren häufig in Multithreading-Applikationen eingesetzt. In der Zwischenzeit ist bekannt, dass dieses Idiom fehlerhaft und deshalb zu vermeiden ist. Natürlich wird auch für diese Anwendung ein alternatives Pattern vorgeschlagen, das die Threadsicherheit garantiert. Simon Müller 10. Juni 2005 Seite 3

5 1 Was ist ein Speichermodell (Memory Model)? Im sequentiellen Fall sind Lese- und Schreiboperationen auf dem globalen Speicher weitgehend transparent. Hingegen ist der Komplexität in Multithreading-Umgebungen keine Grenze gesetzt. Um diesem Problem entgegenwirken zu können muss die Semantik durch ein entsprechendes Modell, dem Speichermodell, definiert werden. Das Speichermodell beschreibt die Beziehung zwischen Variablen in einem Programm und den systemnahen Details bezüglich dem Speichern und Laden vom Memory in einem Computer System. Dabei steht es dem Compiler frei, gewisse Optimierungen vorzunehmen solange die Spezifikationen erfüllt werden. Ein Beispiel hierzu ist das Speichern des Schleifenindexes in einem Register. Ähnliche Optimierungen werden auch vom Prozessor oder vom Cache zur Laufzeit vorgenommen. So kann zum Beispiel das Zurückschreiben vom Cache in den Hauptspeicher zeitlich verschoben werden, damit zusammenhängende Blöcke gemeinsam geschrieben werden und nicht mehrere Cache flushs notwendig sind [9, 10, 14]. 2 Das ursprüngliche Java Memory Model und seine Mängel Das Java Memory Model (JMM) ist das Speichermodell von Java und ist im Kapitel 17 der Java Language Specification (JLS) [5] beschrieben. Die beiden Hauptgründe für die Spezifikation eines Memory Models für Java ist zum einen die angestrebte verminderte Komplexität die dadurch erreicht werden möchte, zum anderen kann die Plattformunabhängigkeit garantiert werden, in dem derselbe Standard für alle Plattformen gilt. Das Modell hat sich allerdings in seiner ursprünglichen Form als unvollständig, schwer verständlich und nicht effizient implementierbar, erwiesen. Eine häufige Fehlerquelle war beispielsweise die falsche Verwendung der Schlüsselwörter synchronized und volatile. So war es für den Java Entwickler sehr schwer, korrekt funktionierenden Multithreading- Code zu schreiben. Ein weiteres Problem betraf das Schlüsselwort final. In bestimmten Situationen wiesen final-felder einen anderen Wert auf als den vom Konstruktor zugewiesenen. Die Konsequenzen waren fatal, zumal unveränderbare Objekte dadurch veränderbar erschienen [8, 9]. Reorderings sind ein fester Bestandteil des Java Memory Models um eine erhöhte Performance zu gewährleisten. Damit steht es dem Compiler frei gewisse Instruktionen umzuordnen, solange die Semantik des Programms nicht verändert wird, d.h. die Ausführung sich wie im sequentiellen Fall verhält (as-ifserial Semantik). Dem Cache ist es erlaubt, Variablen in einer anderen Reihenfolge in den Hauptspeicher zurück zuschreiben als diese vom Programm in den Cache gespeichert wurden. Der Prozessor kann in bestimmten Fällen die Ausführung bestimmter Operationen umsortieren und Instruktionen parallel ausführen. Fehlerhafte Implementierungen führten dabei zu unerwarteten Resultaten [9]. Synchronisierte Operationen haben den Ruf ineffizient zu sein. Deshalb haben sich im Laufe der Jahre verschiedene Idiome entwickelt (z.b. Double-Checked Locking), die vor allem auf die Vermeidung von Synchronisierungsoperationen hinzielen. Doch hat sich gezeigt, dass die meisten dieser Idiome in Unkenntnis oder unter Missachtung des Speichermodells formuliert sind und daher auf ausgewählten Plattformen nicht funktionieren [15]. Folglich war es nur eine Frage der Zeit bis das Java Memory Model überarbeitet wurde. Simon Müller 10. Juni 2005 Seite 4

6 3 JSR-133: Java Memory Model and Thread Specification Die JSR-133 Spezifikation erhebt keinen Anspruch auf neue Konzepte bzw. Features sondern dient lediglich dazu um Unklarheiten der ursprünglichen Spezifikation zu beseitigen. Es wurden einige Anstrengungen unternommen um die Funktionsweise der Threads und des Memorys zu veranschaulichen. Trotzdem werden einige Fragen nicht geklärt, so zum Beispiel wie der Compiler optimiert und Instruktionen umsortiert und wie diese Änderungen das Memory beeinflussen [6]. Die Anpassungen der Spezifikation haben zur Folge, dass die Java Virtual Machines (JVMs) der verschiedenen Plattformen an die neuen Regeln angeglichen werden müssen. Die JSR-133 Experten Gruppe weist dabei auf die folgenden beiden Punkte hin [10]: Die Semantik von final Feldern wurde insofern ausgebaut indem diese Variablen, auch ohne explizite Synchronisation, in Multithreading-Applikationen unveränderbar sind. In der ursprünglichen Spezifikation waren immutable Objekte nicht thread-safe d.h. sie erschienen in bestimmten Situationen veränderlich. Die Semantik von volatile Feldern wurde insofern ausgebaut indem der Zugriff auf diese Variablen nicht mehr ungeordnet geschehen darf, d.h. die Reihenfolge muss beibehalten werden. In der ursprünglichen Spezifikation war die Reihenfolge der Zugriffe auf volatile und non-volatile Variablen beliebig. 3.1 Das Java Memory Model im Detail Bei der Ausarbeitung der Spezifikation für das Java Speichermodell standen zwei gegensätzliche Punkte zur Diskussion. Zum einen muss das Memory Model vom Programmierer bzw. von der Programmiererin verstanden und einfach anwendbar sein, zum anderen soll es die Systemdesigner nicht in der Implementierung einschränken. Ein Modell, das dem Programmierer und der Programmiererin zu gute kommt ist unter dem Namen sequentielle Konsistenz (sequential consistency) bekannt. Es schreibt vor, dass Speichervorgänge sequentiell in der durch das Quellprogramm vorgegebenen Reihenfolge stattfinden müssen. Durch diese Vorgabe sind viele Compiler und Hardware Transformationen nur noch beschränkt durchführbar. Um die Performance dabei nicht zu vernachlässigen, wird der Begriff der sequentiellen Konsistenz leicht umdefiniert [3]: In einem sequentiellen konsistenten System sollen Umsortierungen von Compiler oder Prozessor Instruktionen nicht für den Programmierer oder die Programmiererin sichtbar sein. Durch diese Adaption erhofft man sich, die richtige Balance zwischen Sicherheit und Effizienz gefunden zu haben. Der Programmierer bzw. die Programmiererin muss sich somit nicht um Hardware oder Compiler Transformationen kümmern. Korrekt synchronisierte Programme Welche Bedingungen müssen für korrekt synchronisierte Programme gelten? Um diese Frage zu klären, müssen zuerst einige Begriffe erläutert werden. Nachfolgend werden die wichtigsten Definitionen zusammengefasst aufgelistet [3]: Simon Müller 10. Juni 2005 Seite 5

7 Conflicting Accesses: Das Lesen von oder Schreiben in eine Variable wird als Zugriff auf diese Variable definiert. Zwei Zugriffe auf gemeinsam genutzte Felder oder Arrays gelten als conflicting, sofern mindestens einer der beiden Zugriffe ein Schreibvorgang ist. Synchronization Actions: Unter diesem Begriff versteht man locks, unlocks, sowie das Lesen von und Schreiben in volatile Variablen. Synchronization Order: Die synchronization order beschreibt die Reihenfolge aller synchronisierten Aktionen innerhalb eines Programms. Stimmt die synchronisation order mit der program order überein und entspricht der gelesene Wert einer volatile Variable v dem, in der synchronisation order unmittelbar zuvor geschriebenen Wert derselben Variable v, so ist das Programm korrekt synchronisiert. Happens-Before Order: Stehen zwei Threads zur gleichen Zeit am Eingang des Synchronisationsmonitors, so wird der einen den Zugriff gewährt und der anderen vorerst verwehrt. Data Race: Wenn zwei Threads miteinander in Konflikt stehen und nicht nach happen-before geordnet sind, so spricht man von data race. Correctly Synchronized / Data-Race-Free Program: Ein Programm gilt als korrekt synchronisiert oder data-race-free, genau dann wenn alle sequentially consistent executions des Programms frei von data races sind. Nach Klärung der Begriffsdefinitionen kann nun die Antwort auf die einleitende Frage gegeben werden: Ist ein Programm gemäss der obigen Definition korrekt synchronisiert, so muss vom Java Memory Model die sequentielle Konsistenz garantiert werden. Betrachtet man das Listing 1 dann ist das Resultat r2==2 und r1==1, unter der Bedingung der sequentiellen Konsistenz, ausgeschlossen. Ist das Programm jedoch fehlerhaft synchronisiert, so sind Umsortierungen durch den Compiler möglich, was zu Resultaten wie zum Beispiel r2==2 und r1==1 führen kann [3]. Listing 1: Sequentielle Konsistenz Initialwerte: x==y==0 Thread 1 Thread 2 r2 = x; r1 = y; y = 1; x = 2; Die Konsequenz daraus ist, dass auch unter dem neuen Java Memory Model die zur Verfügung gestellten Hilfsmittel für die Synchronisierung wie synchronized und volatile von der Programmiererin bzw. vom Programmierer richtig eingesetzt werden müssen. 3.2 Der final Modifier In der ursprünglichen Spezifikation des Java Memory Models war es nicht ausgeschlossen, dass sich die sichtbaren Werte von final Feldern änderten. Ein in der Literatur oft beschriebenes Beispiel hierzu ist eine spezielle Implementierung der Klasse String. Simon Müller 10. Juni 2005 Seite 6

8 Ein String kann als Objekt mit drei final Feldern (ein character Array, das Offset in das Array und die Länge) implementiert werden. Der Vorteil dieser Implementierung liegt darin, dass verschiedene String Objekte denselben character Array teilen können und dadurch zusätzliche Objektallokationen und Kopiervorgänge vermieden werden. Die Methode substring() der Klasse String erstellt dabei einen neuen String mit demselben character Array aber mit unterschiedlichem Offset und Länge. String s1 = "/usr/tmp"; String s2 = s1.substring(4); Listing 2: Veränderbare Strings Betrachtet man das Codebeispiel in Listing 2, so ist der nachfolgend beschriebene Effekt gemäss des ursprünglichen Java Memory Models erlaubt: Es ist möglich, dass ein zweiter Thread zuerst einen Offset von 0 (Initialwert) und später den korrigierten Wert von 4 zu sehen bekommt, d.h. der Wert der Variable s2 ändert von "/usr" nach "/tmp". Dieser Effekt ist natürlich verheerend, im Speziellen wenn zum Beispiel das Verzeichnis auf Grund des Wertes der Variable s2 gelöscht werden soll. Dieses Verhalten kam dadurch zu Stande, weil Speichervorgänge ins Memory mit einer möglichen zeitlichen Verzögerung an die anderen Threads mitgeteilt wurden [8, 9]. Die überarbeitete Java Memory Model Spezifikation lässt dieses Verhalten nicht mehr zu, solange ein Objekte regelkonform erstellt wird. Darunter versteht man, dass keine Referenz auf das Objekt während dem Instanzierungsvorgang entfliehen darf. Mit anderen Worten ausgedrückt bedeutet dies, dass die Referenz auf das aktuelle Objekt nicht für andere Threads sichtbar sein darf, solange der Konstruktor nicht komplett abgearbeitet ist. Es ist demzufolge nicht empfehlenswert, die this-referenz im Konstruktor einem statischen Feld zuzuweisen oder damit einen Listener zu registrieren. Diese Aufgaben sind nach Beendigung des Konstruktors durchzuführen, d.h. mittels Methodenaufrufen auf dem instanzierten Objekt [8]. 3.3 Der volatile Modifier Volatile Felder können als Kommunikationsvariablen zwischen Threads angesehen werden. Der Modifier garantiert, dass die Daten des Feldes bei jedem Zugriff direkt vom Hauptspeicher gelesen werden, indem die Werte im Cache ungültig erklärt werden. Des weiteren ist es dem Compiler und der Vitual Machine nicht gestattet volatile Variablenwerte in Registern abzulegen. Beim Schreibvorgang wird mit einem expliziten flushing garantiert, dass die Werte der volatile Felder vom Cache in den Hauptspeicher zurückgeschrieben werden. Durch diese Bestimmungen ist garantiert, dass ein volatile Feld aus der Sicht eines jeden Threads, nie einen veralteten und somit ungültigen Wert aufweist. Im ursprünglichen Memory Model war ein umsortierter Zugriff auf volatile Felder nicht gestattet, jedoch war dieser zwischen volatile und non-volatile Variablen erlaubt. Auf Grund dieser Freizügigkeit war die Überprüfung von Konditionen, wie in Listing 3, nicht garantiert, da eine Umsortierung der Anweisungszugriffe nicht ausgeschlossen werden konnte. Im überarbeiteten Memory Model sind umsortierte Zugriffe zwischen volatile und non-volatile Variablen nicht mehr gestattet. Betrachtet man das Beispiel in Listing 3, unter der Voraussetzung dass der eine Thread die reader-methode und der andere Thread die writer-methode ausführt, so ist nach dem neuen Speichermodell garantiert, dass zum Zeitpunkt in dem die volatile Variable v zu true wird, x bereits den Simon Müller 10. Juni 2005 Seite 7

9 Wert 42 aufweisen muss. So gesehen entspricht der Speichereffekt beim Lesen einer volatile Variable der Anforderung eines Monitors und das Schreiben in dasselbe volatile Feld dem Freigeben desselben Monitors. Damit hat sich die Funktionsweise von volatile sehr stark der Synchronisierung angenähert [2, 4, 9, 11]. Listing 3: Volatile Felder als Konditionsvariablen class VolatileExample { int x = 0; volatile boolean v = false; public void writer() { x = 42; v = true; public void reader() { if (v == true) { // x garantiert den Wert 42 4 Multithreaded Singleton Pattern / Double-checked locking Das Singleton Pattern [1] ist ein häufig angewendetes Idiom in der Programmierung. Es dient dazu, dass von einer Klasse nicht mehrere Objekte instanziert werden können, sondern dass nur eine Instanz sichtbar ist. In einer Multithreading-Umgebung muss das Pattern mit Synchronisationsmechanismen erweitert werden. Ein korrekt funktionierendes Beispiel für ein Singleton in einer Multithreading-Umgebung ist in Listing 4 dargestellt. Listing 4: Thread-safe Singleton Pattern public class Singleton { private static Singleton instance; private Singleton() { public static synchronized Singleton getinstance() { if (instance == null) { Simon Müller 10. Juni 2005 Seite 8

10 instance = new Singleton(); return instance;... Betrachtet man die statische Methode getinstance() im Detail, so fällt auf, dass diese nicht sehr effizient implementiert ist. Grundsätzlich braucht es den Lock-Mechanismus nur solange bis eine Instanz der Klassenvariable instance zugewiesen ist. Danach würde die Methode synchronisationsfrei funktionieren. Es ist allgemein bekannt, dass sich Synchronisationen negativ auf die Performance auswirken. Mit der Idee im Hinterkopf, möglichst viele Synchronisationen zu vermeiden, ist ein weiteres Idiom entstanden, das unter dem Namen double-checked locking bekannt wurde. Der Programmcode ist in Listing 5 abgebildet. Listing 5: Double-checked locking public class Singleton { private static Singleton instance; private Singleton() { public static Singleton getinstance() { if (instance == null) { synchronized(singleton.class) { if (instance == null) { instance = new Singleton(); return instance;... Das Problem scheint gelöst. Der wechselseitige Ausschluss findet nur noch im Initialisierungszustand statt. Zwar muss die Überprüfung auf null innerhalb des synchronized-blocks erneut durchgeführt werden, doch nimmt man die verminderte Code-Übersichtlichkeit meist für eine bessere Performance in kauf. Aber Achtung: So perfekt das Idiom in der Theorie auch scheinen mag, es ist nicht thread-safe! Simon Müller 10. Juni 2005 Seite 9

11 Der Hauptgrund für das Versagen des double-checked locking sind nicht fehlerhafte JVM Implementierungen, sondern die Möglichkeit der out-of-order writes, die durch das Java Memory Model gegeben sind. Somit ist es möglich, dass die Variable instance bereits eine Adresse zugewiesen bekommt, bevor der Singleton-Konstruktor abgearbeitet wurde [7, 12]. Im Listing 6 ist der Vorgang der Zeile instance = new Singleton() in Pseudocode dargestellt. In einem ersten Schritt wird Speicher alloziert, um das zu erstellende Objekt abzulegen. Diese Speicheradresse wird danach der von anderen Threads einsehbaren Variable instance zugewiesen. Ab diesem Zeitpunkt ist instance nicht mehr null, obwohl der Konstruktor die Initialisierungen noch nicht vorgenommen hat. Man muss kein Prophet sein, um vorauszusehen, dass dieses Verhalten zu bedenklichen Problemen führt. Dieser Vorgang ist nicht nur von theoretischer Natur, sondern wird von einigen JIT Compilern angewandt. Listing 6: Pseudocode von instance = new Singleton(); mem = allocate(); instance = mem; ctorsingleton(instance); // Allozierung von Speicher // Zuweisung der Speicheradresse // Initialisierung (Konstruktor) Es stellt sich nun die Frage, ob der Modifier volatile das Problem der out-of-order writes lösen kann. In allen Java Virtual Machines vor der Version 1.5 ist es nicht garantiert. Wird das neue Java Memory Model berücksichtigt, so wird durch markieren des Feldes instance mit volatile gewährleistet, dass eine happens-before Reihenfolge besteht. Dadurch wird die Variable instance für andere Threads erst nach vollständiger Abarbeitung des Konstruktors sichtbar [11, 12]. Trotzdem sollte vom double-checked locking Idiom Abstand genommen werden. In den überarbeiteten Virtual Machines ist der Effizienznachteil von volatile kaum kleiner als von synchronized [11]. Das zu verwendende Pattern, das als effizient und thread-safe gilt, ist unter dem Namen Initialization On Demand Holder idiom bekannt. Es ist in Listing 7 abgebildet. public class Singleton { private Singleton() { Listing 7: Initialization On Demand Holder idiom private static class SingletonHolder { public static Singleton singleton = new Singleton(); public static Singleton getinstance() { return SingletonHolder.singleton; Simon Müller 10. Juni 2005 Seite 10

12 Der entscheidende Vorteil dieses Patterns ist zum einen die einfache Handhabung und zum anderen das Konzept der lazy initialization, das dann zum tragen kommt, wenn das initialisierte Objekt ein statisches Feld einer Klasse mit keinen anderen Methoden oder Feldern ist. Es besagt, dass das Singleton- Objekt erst alloziert wird, wenn zum ersten Mal das Feld singleton referenziert wird [9, 11]. Schlusswort Das neue Java Memory Model hat einen entscheidenden Vorteil gegenüber seinem Vorgänger: Die Spezifikation ist einfacher lesbar und dadurch verständlicher als zuvor. Allein für diese Tatsache hat sich die Mühe gelohnt. Die Korrekturen im Bereich der Modifier volatile und final waren sicherlich erforderlich, jedoch werfen die Effizienzeinbussen bei volatile Feldern einen kleinen Schatten auf die neue Spezifikation. Trotzdem kann das JSR-133 als eines der wichtigsten JSRs der letzten Zeit betrachtet werden, obwohl es keinen Code, keine APIs und keine neuen Sprachfeatures beinhaltet. Simon Müller 10. Juni 2005 Seite 11

13 Bibliographie L1. Literatur [1] Gamma, Erich, et al. Design Patterns: Elements of Reusable Object-Oriented Software. Boston: Addison-Wesley, [2] Lea, Doug. Concurrent Programming in Java: Design Principles and Patterns. 2nd ed. Boston: Addison-Wesley, [3] Manson, Jeremy, William Pugh, Sarita V. Adve. The Java Memory Model. Proceedings of the 32nd ACM SIGPLAN-SIGACT sysposium on Principles of programming languages. Long Beach, California, USA: L2. Internet [4] [5] Mai 2005 [6] [7] Mai 2002 [8] [9] [10] [11] Februar 2004 [12] Februar 2001 [13] Juni 2001 September 2004 [14] [15] Simon Müller 10. Juni 2005 Seite 12