3.4Synchronisation über kritische Abschnitte 

Wenn Threads in Java ein eigenständiges Leben führen, ist dieser Lebensstil nicht immer unproblematisch für andere Threads, insbesondere beim Zugriff auf gemeinsam genutzte Ressourcen. In den folgenden Abschnitten erfahren wir mehr über gemeinsam genutzte Daten und Schutzmaßnahmen beim konkurrierenden Zugriff durch mehrere Threads.

 

3.4.1Gemeinsam genutzte Daten 

Ein Thread besitzt zum einen seine eigenen Variablen, etwa die Objektvariablen, kann aber auch statische Variablen nutzen, wie das folgende Beispiel zeigt:

In diesem Fall können verschiedene Exemplare der Klasse T, die jeweils einen Thread bilden, Daten austauschen, indem sie die Informationen in result ablegen oder daraus entnehmen. Threads können aber auch an einer zentralen Stelle eine Datenstruktur erfragen und dort Informationen entnehmen oder Zugriff auf gemeinsame Objekte über eine Referenz bekommen. Es gibt also viele Möglichkeiten, wie Threads – und damit potenziell parallel ablaufende Aktivitäten – Daten austauschen können.

 

3.4.2Probleme beim gemeinsamen Zugriff und kritische Abschnitte 

Da Threads ihre eigenen Daten verwalten – sie haben alle eigene lokale Variablen und einen Stack –, kommen sie sich gegenseitig nicht in die Quere. Auch wenn mehrere Threads gemeinsame Daten nur lesen, ist das unbedenklich; Schreiboperationen sind jedoch kritisch. Wenn sich zehn Nutzer einen Drucker teilen, der die Ausdrucke nicht als unteilbare Einheit bündelt, lässt sich leicht ausmalen, wie das Ergebnis aussieht. Seiten, Zeilen oder gar einzelne Zeichen aus verschiedenen Druckaufträgen werden bunt gemischt ausgedruckt.

Die Probleme haben ihren Ursprung in der Art und Weise, wie die Threads umgeschaltet werden. Der Scheduler unterbricht zu einem uns unbekannten Zeitpunkt die Abarbeitung eines Threads und lässt den nächsten arbeiten. Wenn nun der erste Thread gerade Programmzeilen abarbeitet, die zusammengehören, und der zweite Thread beginnt, nebenläufig auf diesen Daten zu arbeiten, so ist der Ärger vorprogrammiert. Wir müssen also Folgendes ausdrücken können: »Wenn ich den Job mache, dann möchte ich der einzige sein, der die Ressource – etwa einen Drucker – nutzt.« Erst nachdem der Drucker den Auftrag eines Benutzers fertiggestellt hat, darf er den nächsten in Angriff nehmen.

Kritische Abschnitte

Zusammenhängende Programmblöcke, denen während der Ausführung von einem Thread kein anderer Thread »reinwurschteln« sollte und die daher besonders geschützt werden müssen, nennen sich kritische Abschnitte. Wenn lediglich ein Thread den Programmteil abarbeitet, dann nennen wir dies gegenseitigen Ausschluss oder atomar. Wir könnten das etwas lockerer sehen, wenn wir wüssten, dass innerhalb der Programmblöcke nur von den Daten gelesen wird. Sobald aber nur ein Thread Änderungen vornehmen möchte, ist ein Schutz nötig. Denn arbeitet ein Programm bei nebenläufigen Threads falsch, ist es nicht threadsicher (engl. thread-safe).

Wir werden uns nun Beispiele für kritische Abschnitte anschauen und dann sehen, wie wir diese in Java realisieren können.

Nicht kritische Abschnitte

Wenn mehrere Threads auf das gleiche Programmstück zugreifen, muss das nicht zwangsläufig zu einem Problem führen, und Thread-Sicherheit ist immer gegeben. Immutable Objekte – nehmen wir an, ein Konstruktor belegt einmalig die Zustände – sind automatisch threadsicher, da es keine Schreibzugriffe gibt und bei Lesezugriffen nichts schiefgehen kann. Immutable Klassen wie String oder Wrapper-Klassen kommen daher ohne Synchronisierung aus.

Das Gleiche gilt für Methoden, die keine Objekteigenschaften verändern. Da jeder Thread seine threadeigenen Variablen besitzt – jeder Thread hat einen eigenen Stack –, können lokale Variablen, auch Parametervariablen, beliebig gelesen und geschrieben werden. Wenn zum Beispiel zwei Threads die folgende statische Utility-Methode aufrufen, ist das kein Problem:

Jeder Thread wird eine eigene Variablenbelegung für s haben und ein temporäres Objekt vom Typ StringBuilder referenzieren.

Threadsichere und nicht threadsichere Klassen der Java-Bibliothek

Es gibt in Java viele Klassen, die nicht threadsicher sind – das ist sogar der Standard. So sind etwa alle Format-Klassen, wie MessageFormat, NumberFormat, DecimalFormat, ChoiceFormat, DateFormat und SimpleDateFormat nicht für den nebenläufigen Zugriff gemacht. In der Regel steht das in der Javadoc, etwa bei DateFormat:

»Synchronization. Date formats are not synchronized. It is recommended to create separate format instances for each thread. If multiple threads access a format concurrently, it must be synchronized externally.«

Wer also Objekte nebenläufig verwendet, der sollte immer in der Java-API-Dokumentation nachschlagen, ob es dort einen Hinweis gibt, ob die Objekte überhaupt threadsicher sind.

In einigen wenigen Fällen haben Entwickler die Wahl zwischen threadsicheren und nicht threadsicheren Klassen im JDK:

Tabelle 3.3Threadsichere und nicht threadsichere Klassen

Obwohl es die Auswahl bei den Datenstrukturen im Prinzip gibt, werden Vector und Hashtable dennoch nicht verwendet.

 

3.4.3Punkte nebenläufig initialisieren 

Nehmen wir an, ein Thread T1 möchte ein Point-Objekt p mit den Werten (1,1) belegen und ein zweiter Thread T2 möchte eine Belegung mit den Werten (2,2) durchführen.

Tabelle 3.4Zwei Threads belegen beide den Punkt p.

Beide Threads können natürlich bei einem 2-Kern-Prozessor parallel arbeiten, aber da sie auf gemeinsame Variablen zugreifen, ist der Zugriff auf x bzw. y von p trotzdem sequenziell. Um es nicht allzu kompliziert zu machen, vereinfachen wir unser Ausführungsmodell so, dass wir zwar zwei Threads laufen haben, aber nur jeweils einer ausgeführt wird. Dann ist es möglich, dass T1 mit der Arbeit beginnt und x = 1 setzt. Da der Thread-Scheduler einen Thread jederzeit unterbrechen kann, kann nun T2 an die Reihe kommen, der x = 2 und y = 2 setzt. Wird dann T1 wieder Rechenzeit zugeteilt, darf T1 an der Stelle weitermachen, wo er aufgehört hat, und y = 1 folgt. In einer Tabelle ist das Ergebnis noch besser zu sehen:

Tabelle 3.5Mögliche sequenzielle Abarbeitung der Punktbelegung

Wir erkennen das nicht beabsichtigte Ergebnis (2,1), es könnte aber auch (1,2) sein, wenn wir das gleiche Szenario beginnend mit T2 durchführen. Je nach zuerst abgearbeitetem Thread wäre jedoch nur (1,1) oder (2,2) korrekt. Die Threads sollen ihre Arbeit aber atomar erledigen, denn die Zuweisung bildet einen kritischen Abschnitt, der geschützt werden muss. Standardmäßig sind die zwei Zuweisungen nichtatomare Operationen und können unterbrochen werden. Um dies an einem Beispiel zu zeigen, sollen zwei Threads ein Point-Objekt verändern. Die Threads belegen x und y immer gleich, und immer dann, wenn sich die Koordinaten unterscheiden, soll es eine Meldung geben:

Listing 3.18com/tutego/insel/thread/concurrent/ParallelPointInit.java, main()

Die interessanten Zeilen sind mit * markiert. p.x = x; p.y = y; belegt die Koordinaten neu, und int xc = p.x, yc = p.y; liest die Koordinaten erneut aus. Würden Belegung und Auslesen in einem Rutsch passieren, dürfte überhaupt keine unterschiedliche Belegung von x und y zu finden sein. Doch das Beispiel zeigt es anders:

Was wir mit den nebenläufigen Punktinitialisierungen vor uns haben, sind Effekte, die von den Ausführungszeiten der einzelnen Operationen abhängen. In Abhängigkeit von dem Ort der Unterbrechung wird ein fehlerhaftes Verhalten produziert. Dieses Szenario nennt sich im Englischen race condition bzw. race hazard (zu Deutsch auch Wettlaufsituation).

 

3.4.4i++ sieht atomar aus, ist es aber nicht * 

Das Beispiel von vorhin ist plastisch und einleuchtend, weil zwischen Anweisungen unterbrochen werden kann. Das Problem liegt aber noch tiefer. Schon einfache Anweisungen wie i++ müssen geschützt werden. Um dies zu verstehen, wollen wir einen Blick auf folgende Zeilen werfen:

Listing 3.19com/tutego/insel/thread/IPlusPlus.java, IPlusPlus

Die Objektmethode foo() erhöht die statische Variable i. Um zu erkennen, dass i++ ein kritischer Abschnitt ist, sehen wir uns den dazu generierten Bytecode[ 34 ](Machbar ist das zum Beispiel mit dem jeder Java-Distribution beiliegenden Dienstprogramm javap und der Option -c.) für die Methode foo() an:

Die einfach aussehende Operation i++ ist also etwas komplizierter. Zuerst wird i gelesen und auf dem Stack abgelegt. Danach wird die Konstante 1 auf den Stack gelegt, und anschließend addiert iadd beide Werte. Das Ergebnis steht wiederum auf dem Stack und wird von putstatic zurück in i geschrieben.

Wenn jetzt auf die Variable i von zwei Threads A und B gleichzeitig zugegriffen wird, kann folgende Situation eintreten:

• Thread A holt sich den Wert von i in den internen Speicher, wird dann aber unterbrochen. Er kann das um 1 erhöhte Resultat nicht wieder i zuweisen.

• Nach der Unterbrechung von A kommt Thread B an die Reihe. Auch er besorgt sich i, kann aber i + 1 berechnen und das Ergebnis in i ablegen. Dann ist B beendet, und der Scheduler beachtet Thread A.

• Jetzt steht in i das von Thread B um 1 erhöhte i. Thread A addiert nun 1 zu dem gespeicherten alten Wert von i und schreibt dann nochmals denselben Wert wie Thread B zuvor. Insgesamt wurde die Variable i nur um 1 erhöht, obwohl zweimal inkrementiert werden sollte. Jeder Thread hat für sich gesehen das korrekte Ergebnis berechnet.

Wenn wir unsere Methode foo() atomar ausführen, haben wir das Problem nicht mehr, weil das Lesen aus i und das Schreiben zusammen einen unteilbaren, kritischen Abschnitt bilden.

 

3.4.5Kritische Abschnitte schützen 

Beginnen wir mit einem anschaulichen Alltagsbeispiel. Gehen wir aufs Klo, schließen wir die Tür hinter uns. Möchte jemand anderes auf die Toilette, muss er warten. Vielleicht kommen noch mehrere dazu, die müssen dann auch warten, und eine Warteschlage bildet sich. Dass die Toilette besetzt ist, signalisiert die abgeschlossene Tür. Jeder Wartende muss so lange vor dem Klo ausharren, bis das Schloss geöffnet wird, selbst wenn der auf der Toilette Sitzende nach einer langen Nacht einnicken sollte.

Wie übertragen wir das auf Java? Wenn die Laufzeitumgebung nur einen Thread in einen Block lassen soll, ist ein Monitor [ 35 ](Der Begriff geht auf C. A. R. Hoare zurück, der in seinem Aufsatz »Communicating Sequential Processes« von 1978 erstmals dieses Konzept veröffentlichte.) nötig. Ein Monitor wird mithilfe eines Locks (zu Deutsch Schloss) realisiert, den ein Thread öffnet oder schließt. Tritt ein Thread in den kritischen Abschnitt ein, muss Programmcode wie eine Tür abgeschlossen werden (engl. lock). Erst wenn der Abschnitt durchlaufen wurde, darf die Tür wieder aufgeschlossen werden (engl. unlock), und ein anderer Thread kann den Abschnitt betreten.

Java-Konstrukte zum Schutz der kritischen Abschnitte

Wenn wir auf unser Punkte-Problem zurückkommen, so stellen wir fest, dass zwei Zeilen auf eine Variable zugreifen:

Diese beiden Zeilen bilden also einen kritischen Abschnitt, den jeweils nur ein Thread betreten darf. Wenn also einer der Threads mit p.x = x beginnt, muss er so lange den exklusiven Zugriff bekommen, bis er mit yc = p.y endet.

Aber wie wird nun ein kritischer Abschnitt bekannt gegeben? Zum Markieren und Abschließen dieser Bereiche gibt es zwei Konzepte:

Tabelle 3.6Lock-Konzepte

Beim synchronized entsteht Bytecode, der der JVM sagt, dass ein kritischer Block beginnt und endet. So überwacht die JVM, ob ein zweiter Thread warten muss, wenn er in einen synchronisierten Block eintritt, der schon von einem Thread ausgeführt wird. Bei Lock ist das Ein- und Austreten explizit vom Entwickler programmiert, und vergisst er das, ist das ein Problem. Und während bei der Lock-Implementierung das Objekt, an dem synchronisiert wird, offen hervortritt, ist das bei synchronized nicht so offensichtlich. Hier gilt es, zu wissen, dass jedes Objekt in Java implizit mit einem Monitor verbunden ist. Auf diesen Unterschied kommen wir in Abschnitt 3.4.9, »Mit synchronized synchronisierte Blöcke«, noch einmal zurück. Da moderne Programme aber mittlerweile mit Lock-Objekten arbeiten, tritt die synchronized-Möglichkeit, die schon Java 1.0 zur Synchronisation bot, etwas in den Hintergrund.

Fassen wir zusammen: Nicht threadsichere Abschnitte müssen geschützt werden. Sie können entweder mit synchronized geschützt werden, bei dem der Eintritt und Austritt implizit geregelt ist, oder durch Lock-Objekte. Befindet sich dann ein Thread in einem geschützten Block und möchte ein zweiter Thread in den Abschnitt, muss er so lange warten, bis der erste Thread den Block wieder freigibt. So ist die Abarbeitung über mehrere Threads einfach synchronisiert, und das Konzept eines Monitors gewährleistet seriellen Zugriff auf kritische Ressourcen. Die kritischen Bereiche sind nicht per se mit einem Monitor verbunden, sondern werden eingerahmt, und dieser Rahmen ist mit einem Monitor (Lock) verbunden.

Mit dem Abschließen und Aufschließen werden wir uns noch intensiver in den folgenden Abschnitten beschäftigen.

 

3.4.6Kritische Abschnitte mit ReentrantLock schützen 

Lock ist eine Schnittstelle mit Methoden, mit der sich ein kritischer Block markieren lässt. Ein Abschnitt beginnt mit lock() und endet mit unlock(). Eine Implementierung der Schnittstelle ist ReentrantLock.

Listing 3.20com/tutego/insel/thread/concurrent/ParallelPointInitSync.java, main()

Mit dieser Implementierung wird keine Ausgabe auf dem Bildschirm folgen.

Die Schnittstelle java.util.concurrent.locks.Lock

Lock ist eine Schnittstelle, von der ReentrantLock die wichtigste Implementierung ist. Mit ihr lässt sich der Block betreten und verlassen.

• void lock()
  Wartet so lange, bis der ausführende Thread den kritischen Abschnitt betreten kann, und markiert ihn dann als betreten. Hat schon ein anderer Thread an diesem Lock-Objekt ein lock() aufgerufen, so muss der aktuelle Thread warten, bis der Lock wieder frei ist. Hat der aktuelle Thread schon den Lock, kann er bei der Implementierung ReentrantLock wiederum lock() aufrufen und sperrt sich nicht selbst.

• boolean tryLock()
  Wenn der kritische Abschnitt sofort betreten werden kann, ist die Funktionalität wie bei lock(), und die Rückgabe ist true. Ist der Lock gesetzt, so wartet die Methode nicht wie lock(), sondern kehrt mit einem false zurück.

• boolean tryLock(long time, TimeUnit unit) throws InterruptedException
  Versucht in der angegebenen Zeitspanne den Lock zu bekommen. Das Warten kann mit interrupt() auf dem Thread unterbrochen werden, was tryLock() mit einer Exception beendet.

• void unlock()
  Verlässt den kritischen Block.

• void lockInterruptibly() throws InterruptedException
  Wartet wie lock(), um den kritischen Abschnitt betreten zu dürfen, kann aber mit einem interrupt() von außen abgebrochen werden (der lock()-Methode ist ein Interrupt egal). Implementierende Klassen müssen diese Vorgabe nicht zwingend umsetzen, sondern können die Methode auch mit einem einfachen lock() realisieren. ReentrantLock implementiert lockInterruptibly() erwartungsgemäß.

Klasse ReentrantLock

Die Implementierung ReentrantLock kann noch ein bisschen mehr als lock() und unlock():

• ReentrantLock()
  Erzeugt ein neues Lock-Objekt, das nicht dem am längsten Wartenden den ersten Zugriff gibt.

• ReentrantLock(boolean fair)
  Erzeugt ein neues Lock-Objekt mit fairem Zugriff, gibt also dem am längsten Wartenden den ersten Zugriff.

• boolean isLocked()
  Fragt an, ob der Lock gerade genutzt wird und im Moment kein Betreten möglich ist.

• final int getQueueLength()
  Ermittelt, wie viele auf das Betreten des Blocks warten.

• int getHoldCount()
  Gibt die Anzahl der erfolgreichen lock()-Aufrufe ohne passendes unlock() zurück. Sollte nach Beenden des Vorgangs 0 sein.

Abbildung 3.7Die Klasse ReentrantLock implementiert die Schnittstelle Lock.

Schnittstelle ReentrantReadWriteLock

Die Klasse ReentrantLock blockt bei jedem lock() und lässt keinen Interessenten in den kritischen Abschnitt. Viele Szenarien sind jedoch nicht so streng, und so kommt es zu Situationen, in denen lesender Zugriff durchaus von mehreren Parteien möglich ist, schreibender Zugriff aber blockiert wird.

Für diese Lock-Situation gibt es die Schnittstelle ReadWriteLock, die nicht von Lock abgeleitet ist, sondern mit readLock() und writeLock() die Lock-Objekte liefert. Die bisher einzige Implementierung der Schnittstelle ist java.util.concurrent.locks.ReentrantReadWriteLock. Ein Programmausschnitt könnte so aussehen:

Abbildung 3.8Die Klasse ReentrantReadWriteLock implementiert ReadWriteLock.

Das Schreiben sperren, das Lesen durchlassen *

In Java sind drei Typen von Datenstrukturen essenziell: Listen (dynamische Felder), Mengen (Elemente gibt es nur einmal) und Assoziativspeicher (ein Objekt ist mit einem anderen Objekt verbunden). Die Operationen der Datenstrukturen beschreiben Schnittstellen, und konkrete Klassen realisieren sie. Dabei sind drei Implementierungen hervorzuheben: ArrayList (Implementierung für Listen), TreeSet (sortierte Menge) und HashSet (Assoziativspeicher). Eine Besonderheit der meisten java.util-Klassen ist, dass sie nicht gegen nebenläufige Zugriffe gesichert sind, also Datenmüll enthalten können, wenn mehrere Threads gleichzeitig Operationen durchführen.

Java bietet zwar auch threadsichere Datenstrukturen, doch wollen wir mit ReentrantReadWriteLock zwei Datenstrukturen nachträglich synchronisieren, sodass nebenläufige Lesezugriffe erlaubt und Schreibzugriffe nur atomar sind.

Nehmen wir an, eine Liste soll Strings speichern. Dann müssen wir das get(…) über den Lese-Lock anmelden und das set(…) über den Schreib-Lock sperren. Das Ganze sieht so aus:

Listing 3.21com/tutego/insel/thread/concurrent/ConcurrentReadWriteStringList.java, ConcurrentReadWriteStringList

Der readLock und der writeLock kommen zwingend vom gleichen ReentrantReadWriteLock und koordinieren sich dadurch.

Die Absicherung, dass beliebig viele Leser, aber nur ein Schreiber erlaubt sind, sieht in der Programmierung immer gleich aus. Daher noch ein zweites Beispiel: HashMap ist eine Java-Klasse, die über put(…) eine Assoziation herstellt und über get(…) erfragt. Im Unterschied zum vorangegangenen Beispiel ist die von uns angebotene Datenstruktur selbst generisch deklariert:

Listing 3.22com/tutego/insel/thread/concurrent/ConcurrentReadWriteMap.java

Wenn Lese- und Schreiboperationen nach dem optimistischen Locking durchgeführt werden sollen, kann die Klasse StampedLock weiterhelfen. Sie ist neu in Java 8.

 

3.4.7Synchronisieren mit synchronized 

Schon seit Java 1.0 können kritische Abschnitte mit synchronized geschützt werden. Im einfachsten Fall markiert der Modifizierer synchronized die gesamte Methode. Ein betretender Thread setzt bei Objektmethoden den Monitor des this-Objekts und bei statischen Methoden den Lock des dazugehörigen Class-Objekts.

Betritt ein Thread A eine synchronisierte Methode eines Objekts O und versucht anschließend Thread B eine synchronisierte Methode des gleichen Objekts O aufzurufen, muss der nachfolgende Thread B so lange warten, bis A wieder aus dem synchronisierten Teil austritt. Das geschieht, wenn der erste Thread A die Methode verlässt, denn mit dem Verlassen einer Methode – oder auch einer Ausnahme – gibt die JVM automatisch den Lock frei. Die Dauer eines Locks hängt folglich mit der Dauer des Methodenaufrufs zusammen, was zur Konsequenz hat, dass längere kritische Abschnitte eine mögliche parallele Abarbeitung einschränken und zu längeren Wartezeiten führen. Eine Endlosschleife in der synchronisierten Methode gäbe den Lock niemals frei.

Das aus IPlusPlus.java bekannte Problem mit dem i++ lässt sich mit synchronized einfach lösen:

Bei einem Konflikt (mehrere Threads rufen foo() auf) verhindert synchronized, dass sich mehr als ein Thread gleichzeitig im kritischen Abschnitt, dem Rumpf der Methode foo(), befinden kann. Dies bezieht sich nur auf mehrere Aufrufe von foo() für dasselbe Objekt. Zwei verschiedene Threads können durchaus nebenläufig die Methode foo() für unterschiedliche Objekte ausführen.

Neben diesem speziellen Problem für atomares Verändern von Variablen lassen sich auch Klassen aus dem Paket java.util.concurrent.atomic verwenden – sie werden in Abschnitt 3.7.2, »Das Paket java.util.concurrent.atomic«, vorgestellt.

Bei einem orthografisch anspruchsvollen Wort wie synchronized ist es praktisch, dass Eclipse auch Schlüsselwörter vervollständigt. Hier reicht ein Tippen von sync und (Strg) + Leertaste für einen Dialog.

Hat der aktuelle Thread den Lock? *

Die statische Methode Thread.holdsLock(…) zeigt an, ob der aktuelle Thread den Lock hält:

Listing 3.23com/tutego/insel/thread/HoldsLockDemo.java, main()

Und Thread.holdsLock(this) wird etwa in einer Objektmethode feststellen können, ob der Lock durch eine synchronisierte Methode oder einen synchronized(this)-Block gelockt ist.

 

3.4.8Synchronized-Methoden der Klasse StringBuffer * 

Wir wollen uns anhand einiger Beispiele noch ansehen, an welchen Objekten der Monitor bzw. Lock gespeichert wird. Zunächst betrachten wir die Methode charAt(…) der Klasse StringBuffer und versuchen zu verstehen, warum die Methode synchronized ist.

Neben charAt(…) sind noch eine ganze Reihe anderer Methoden synchronisiert, etwa getChars(…), setCharAt(…) und append(…). Bei einer synchronized-Methode wird also der Lock bei einem konkreten StringBuffer-Objekt gespeichert. Wäre die Methode charAt(…) nicht atomar, dann könnte es passieren, dass durch Multithreading zwei Threads das gleiche StringBuffer-Objekt bearbeiten. Probleme können sich zum Beispiel dann ergeben, wenn ein Thread gerade den String verkleinert und gleichzeitig charAt(…) aufgerufen wird. Auch wenn zuerst charAt(…) einen gültigen Index feststellt, dann aber der StringBuffer verkleinert wird, gibt es ein Problem. Dann wäre nämlich der Index ungültig und value[index] fehlerhaft. Da aber charAt(…) synchronisiert ist, kann kein anderer Thread dasselbe StringBuffer-Objekt über synchronisierte Methoden modifizieren.

 

3.4.9Mit synchronized synchronisierte Blöcke 

Wenn wir mit Lock-Objekten arbeiten, können wir den Block so fein wählen, wie es erforderlich ist. Mit synchronized haben wir bisher nur eine gesamte Methode sperren können, was in manchen Fällen etwas viel ist. Dann kann eine allgemeinere Variante in Java eingesetzt werden, die nur einen Block synchronisiert. Dazu schreiben wir in Java Folgendes:

Der Block wird in die geforderten geschweiften Klammern gesetzt, und hinter dem Schlüsselwort in Klammern muss ein Objekt stehen, das den zu verwendenden Monitor besitzt. Die Konsequenz ist die Möglichkeit, über einen beliebigen Monitor zu synchronisieren und nicht unbedingt über den Monitor des Objekts, für das die synchronisierte Methode aufgerufen wurde, wie es bei synchronisierten Objektmethoden üblich ist.

Statisch synchronisierte Blöcke

Nicht nur Objektmethoden, sondern auch Klassenmethoden können synchronized sein. Doch die Nachbildung in einem Block sieht etwas anders aus, da es keine this-Referenz gibt. Hier kann ein Object-Exemplar für einen Lock herhalten, der extra für die Klasse angelegt wird. Dies ist eines der seltenen Beispiele, in denen ein Exemplar der Klasse Object Sinn ergibt:

Listing 3.24com/tutego/insel/thread/StaticSync.java

Alternativ könnten wir auch das zugehörige Class-Objekt einsetzen. Wir müssen das entsprechende Klassenobjekt dann nur mittels StaticSync.class erfragen. Würden wir gleich mit Lock-Objekten arbeiten, stellte sich die Frage erst gar nicht.

 

3.4.10Dann machen wir doch gleich alles synchronisiert! 

In nebenläufigen Programmen kann es schnell zu unerwünschten Nebeneffekten kommen. Das ist auch der Grund, warum threadlastige Programme schwer zu debuggen sind. Warum sollten wir also nicht alle Methoden synchronisieren? Wäre dann nicht das Problem aus der Welt geschafft? Prinzipiell würde das einige Probleme lösen, doch hätten wir uns damit andere Nachteile eingefangen:

• Methoden, die synchronisiert sind, müssen von der JVM besonders bedacht werden, damit keine zwei Threads die Methode für das gleiche Objekt ausführen. Wenn also ein zweiter Thread in die Methode eintreten möchte, kann er das nicht einfach machen, sondern muss vielleicht erst neben vielen anderen Threads warten. Es muss also eine Datenstruktur geben, in der wartende Threads eingetragen und ausgewählt werden. Das kostet zusätzlich Zeit und ist im Vergleich zu einem normalen Methodenaufruf teurer.

• Zusätzlich kommt ein Problem hinzu, wenn eine nicht notwendigerweise, also überflüssigerweise, synchronisierte Methode eine Endlosschleife oder lange Operationen durchführt. Dann warten alle anderen Threads auf die Freigabe, und das kann im Fall der Endlosschleife ewig sein. Auch bei Multiprozessorsystemen profitieren wir nicht von dieser Programmiertechnik. Unnötig und falsch synchronisierte Blöcke machen die Vorteile von Mehrprozessormaschinen zunichte.

• Wenn alle Methoden synchronisiert sind, steigt auch die Gefahr eines Deadlocks. In den folgenden Abschnitten erfahren wir etwas mehr über den Fall, dass zwei Threads wechselseitig auf Ressourcen eines jeweils anderen Threads zugreifen wollen und sich dabei im Weg stehen.

Ist der gesamte Zugriff auf ein Objekt synchronisiert und kann kein zweiter Thread irgendwelche Eigenschaften nebenläufig zu einem anderen Thread nutzen, nennt sich das Objekt voll synchronisiert im Gegensatz zu teilsynchronisiert. Sind einige Methoden der Klasse nicht synchronisiert, kann ein zweiter Thread nebenläufig zu den synchronisierten Blöcken an die Eigenschaften gehen.

 

3.4.11Lock-Freigabe im Fall von Exceptions 

Kommt es innerhalb eines synchronized-Blocks bzw. innerhalb einer synchronisierten Methode zu einer nicht überprüften RuntimeException, wird die JVM den Lock automatisch freigeben. Der Grund: Die Laufzeitumgebung gibt den Lock automatisch frei, wenn der Thread den synchronisierten Block verlässt, was bei einer Exception der Fall ist.

Werden die mit dem Schlüsselwort synchronized geschützten Blöcke durch Lock-Objekte umgesetzt, ist darauf zu achten, die Locks auch im Exception-Fall wieder freizugeben. Ein finally mit unlock() kommt da gerade recht, denn finally wird ja immer ausgeführt, egal, ob es einen Fehler gab oder nicht:

Listing 3.25com/tutego/insel/thread/concurrent/UnlockInFinally.java, main()

Nach dem lock() liefert getHoldCount() 1, da ein Thread den Block betreten hat. Die Division durch null provoziert eine RuntimeException, und finally gibt den Lock frei. Die Ausnahme wird abgefangen, und getHoldCount() liefert wieder 0, da finally das unlock() ausgeführt hat. Würden wir die Zeile mit unlock() auskommentieren, so würde getHoldCount() weiterhin 1 liefern, was ein Fehler ist.

 

3.4.12Deadlocks 

Ein Deadlock (zu Deutsch etwa tödliche Umarmung) kommt beispielsweise dann vor, wenn ein Thread A eine Ressource belegt, die ein anderer Thread B haben möchte, und Thread B eine Ressource belegt, die A gerne nutzen würde. In dieser Situation können beide nicht vor und zurück und befinden sich in einem dauernden Wartezustand. Deadlocks können in Java-Programmen nicht erkannt und verhindert werden. Uns fällt also die Aufgabe zu, diesen ungünstigen Zustand gar nicht erst herbeizuführen.

Das nächste Beispiel soll über eine Verklemmung einen Deadlock provozieren. Zwei Threads wetteifern um die Lock-Objekte lock1 und lock2. Dabei kommt es zu einem Deadlock, da der eine genau den einen Lock besetzt, den der jeweils andere zum Weiterarbeiten benötigt:

Listing 3.26com/tutego/insel/thread/Deadlock.java

In der Ausgabe sehen wir nur zwei Zeilen, und schon hängt das gesamte Programm:

Eine Lösung des Problems wäre, bei geschachteltem Synchronisieren auf mehrere Objekte diese immer in der gleichen Reihenfolge zu belegen, also etwa immer erst lock1, dann lock2. Bei unbekannten, dynamisch wechselnden Objekten muss dann unter Umständen eine willkürliche Ordnung festgelegt werden.

 

3.4.13Mit synchronized nachträglich synchronisieren * 

Einige Java-Methoden in der Standardbibliothek sind synchronisiert, bei anderen haben die Entwickler auf eine Synchronisierung verzichtet. Nichtsynchronisierte Methoden bilden eindeutig die Mehrheit. Wenn keine ausdrücklichen Gründe für die Synchronisierung vorliegen und im Allgemeinen nur maximal ein Thread die Methode gleichzeitig aufruft, muss der Entwickler eine Absicherung nicht standardmäßig in Erwägung ziehen. Synchronisierung führt zu Geschwindigkeitsverlusten, und warum sollten wir – wenn keine Nebenläufigkeit gefragt ist – für etwas bezahlen, was keiner bestellt hat?

Im ersten Beispiel haben wir die Initialisierung eines Point-Objekts betrachtet. Dass der direkte Zugriff auf zwei Variablen nicht atomar sein kann, ist klar. Doch auch der Methodenaufruf über die nichtsynchronisierte Methode setLocation(…) bringt uns nicht weiter, weil ein Thread in dieser Methode unterbrochen werden könnte.

Wollen wir nachträglich sichergehen, dass setLocation(…) atomar ist, können wir über zwei Dinge nachdenken:

1. Wir verwenden ein Lock-Objekt, das allen Threads zugänglich ist. Das Objekt nutzen sie zur Synchronisation.

2. Wir besorgen uns einen Monitor auf das Point-Objekt und synchronisieren über diesen.

Die erste Variante haben wir schon gesehen, sodass wir uns ein Beispiel für die zweite Variante anschauen:

Auf diese Weise kann jeder Aufruf einer nichtsynchronisierten Methode nachträglich synchronisiert werden. Jedoch muss dann jeder Zugriff wiederum mit einem synchronized-Block geschützt sein, sonst besteht keine Sicherheit, weil setLocation(…) selbst auf keinen Monitor achtet. Ruft demnach ein anderer Thread setLocation(…) außerhalb des synchronized-Blocks auf, ist die atomare Bearbeitung nichtig.

Wrapper

Einen anderen Weg gehen komplette Wrapper, die sich durch Delegation oder Vererbung implementieren lassen. Für unseren Punkt können wir zum Beispiel eine Unterklasse SynchronizedPoint implementieren, die alle kritischen Methoden überschreibt, die Signatur mit synchronized erweitert und im Rumpf ein super.methode() durchführt. Wrapper gibt es für Datenstrukturen aus der Collection-API mit statischen Methoden der Art synchronizedDatenstruktur(Datenstruktur) – etwa für Listen:

 

3.4.14Monitore sind reentrant – gut für die Geschwindigkeit * 

Betritt das Programm eine synchronisierte Methode, bekommt es den Monitor des aufrufenden Objekts. Wenn diese Methode eine andere aufruft, die am gleichen Objekt synchronisiert ist, kann sie sofort eintreten und muss nicht warten. Diese Eigenschaft heißt reentrant. Ohne diese Möglichkeit würde Rekursion nicht funktionieren!

Wenn das Programm den synchronisierten Block betritt, reserviert er den Monitor und kann alle synchronisierten Methoden ohne weitere Überprüfungen ausführen. Im Allgemeinen reduziert diese Technik aber auch die Nebenläufigkeit, da der kritische Abschnitt künstlich vergrößert wird. Die Technik kann geschwindigkeitssteigernd sein, wenn viele synchronisierte Methoden hintereinander aufgerufen werden.

Die Klasse ReentrantLock verwaltet den Zähler – er geht bis 2³¹ – selbst, und einige Methoden geben Zugriff auf die Informationen, die meistens zum Testen nützlich sind. Mit isLocked() finden wir heraus, ob der Lock frei ist oder nicht. isHeldByCurrentThread() liefert true, wenn der ausführende Thread den Lock verwendet. getHoldCount() liefert die Anzahl der Anfragen, die der aktuelle Thread an den Lock gestellt hat. Ist die Rückgabe null, so schließt der aktuelle Thread nicht ab, doch könnte dies wohl ein anderer Thread erledigen. getQueueLength() gibt eine (durch Race Conditions mögliche) Schätzung über die Anzahl der wartenden Threads ab, die lock() aufgerufen haben.

 

3.4.15Synchronisierte Methodenaufrufe zusammenfassen * 

Synchronisierte Methoden stellen sicher, dass bei mehreren nebenläufig ausführenden Threads die Operationen atomar ausgeführt werden. Das gilt jedoch ausschließlich für jede synchronisierte Methode, aber nicht für eine Sequenz von synchronisierten Methoden. Wir wissen zum Beispiel, dass StringBuffer alle Methoden synchronisiert und daher der StringBuffer bei nebenläufigen Zugriffen keine inkonsistenten Zustände erzeugt. Was geschieht, wenn zwei Threads auf den folgenden Block zugreifen, wobei sb eine Variable ist, die auf einen gemeinsamen StringBuffer zeigt?

Greifen zwei Threads – nennen wir sie T1 und T2 – auf sb zu, erzeugen möglicherweise beide zusammen die folgende Zeichenkette: abcabcdefgdhihij… Das Ergebnis ist logisch, denn synchronized bedeutet nur, dass zwei Threads eine einzelne Operation atomar ausführen, aber kein Bündel.

Diese Aufgabe löst ein synchronisierter Block ausgezeichnet:

Betritt der erste Thread den synchronisierten Block, schließt er ab, sodass andere Threads warten müssen. Der betretende Thread selbst kann aber, weil er den Monitor des StringBuffer schon besitzt, reentrant die anderen synchronisierten Methoden aufrufen.

Das Beispiel zeigt, wie gut sich ein synchronized-Block nutzen lässt, wenn an anderen Objekten synchronisiert wird. Mit einem Lock-Objekt könnten wir hier nicht arbeiten, weil es zwar die einzelnen append(…)-Aufrufe zusammenfasst, aber von außen eine Unterbrechung nicht verhindern kann. Wenn sich ein zweiter Thread in die Aufrufkette mogelt, kann er jedes Mal, wenn ein append(…) verlassen und dabei der Monitor frei wird, ein neues append(…) aufrufen und so außerhalb des lock()/unlock()-Blocks eintreten.