9.11 Variablen mit volatile kennzeichnen
Die JVM arbeitet bei den Ganzzahl-Datentypen kleiner gleich int intern nur mit einem int. Doch obwohl es auch für die Datentypen, die größer als 32 Bit sind, also long und double, einzelne Bytecode-Befehle gibt, ist nicht gesichert, dass die Operationen auf diesen Datentypen unteilbar sind. Es kann also passieren, dass ein Thread mitten in einer long- oder double-Operation von einem anderen Thread verdrängt wird. Greifen zwei Threads auf die gleiche lange Variable zu, so könnte es passieren, dass der eine Thread eine Hälfte schreibt und der andere Thread die andere.
Beispiel Eine long-Variable l ist mit dem Wert 0x12345678 90abcdefL initialisiert. Aus Gründen der Übersichtlichkeit ist in der ersten Hälfte des long-Werts ein Leerzeichen eingefügt. Jetzt versuchen zwei Threads gleichzeitig, die Variable zu ändern.
l = 0x00000000 00000000L; l = 0xabcdef12 34567890L;
|
|
Wenn hier der erste Thread den ersten Teil der long-Variablen mit 00000000 beschreibt und dann ein Kontextwechsel stattfindet, ist die Variable fälschlicherweise mit 00000000 90abcdefL initialisiert. Kommt nun nach dem Kontextwechsel der zweite Thread, so kann dieser vielleicht auch nur den ersten Teil der Variable mit abcdef12 beschreiben, so dass danach die Variable den völlig krummen Wert abcdef12 90abcdefL enthält.
|
Um das zu vermeiden, können die Objekt- und Klassenvariablen mit dem Modifizierer volatile deklariert werden. Die Zugriffsoperationen werden auf diesen Variablen dann atomar ausgeführt. Der Modifizierer ist bei lokalen Variablen nicht gestattet.
Das Schlüsselwort volatile findet sich im Quellcode sehr selten, und in der ersten Java-Betaversion wurde es überhaupt nicht benutzt.
Zwischenspeicherung untersagen
volatile beugt zusätzlich einem anderen Problem vor. Während der Berechnung könnte die Laufzeitumgebung Inhalte von Variablen im Prozessorspeicher (zum Beispiel Register) zwischengespeichert haben. Das passiert etwa, wenn in einer Schleife ein Wert immer hoch gezählt wird, der in einer Objektvariablen gespeichert wird.
Eine Laufzeitumgebung könnte den Zugriff auf Objektvariablen optimieren, indem zuerst der Variableninhalt in eine interne lokale Variable kopiert und anschließend, nach einer Berechnung, das Ergebnis zurückgespeichert wird. Ist cnt eine Objektvariable, dann könnte folgende Schleife von der Laufzeitumgebung optimiert werden:
for ( int i = 0; i < 1000000; i++ )
cnt++;
Eine optimierende Laufzeitumgebung könnte nun auf die Idee kommen, nicht bei jedem Schleifendurchlauf die Objektvariable zu erhöhen, sondern nur zum Ende. Wenn die Umgebung zuerst i in eine interne lokale Variable kopiert, dann die gesamte Schleife ausführt und erst anschließend den internen Wert nach i zurückkopiert, haben wir viel Zeit gespart, denn der Zugriff auf eine lokale Variable, die im Register des Prozessors leben kann, ist wesentlich schneller als der Zugriff auf eine Objektvariable. Dies ist im Übrigen eine beliebte Strategie, um die Performanz eines Programms zu steigern. Doch mit dieser internen Optimierung kommt es zu schwer kontrollierbaren Nebeneffekten, und Änderungen am Wert von i sind nicht sofort für andere Threads sichtbar, denen damit die Information über die einzelnen Inkrementschritte fehlt.
Auch hier hilft wieder das ungewöhnliche Schlüsselwort. Ist die Variable mit volatile gekennzeichnet, wird das Ergebnis nicht im Zwischenspeicher belassen, sondern immer aktualisiert. Die parallelen Threads sehen somit immer den korrekten Variablenwert, da er vor jeder Benutzung aus dem Speicher gelesen und nach einer Änderung sofort wieder zurückgeschrieben wird.
|
