Galileo Computing < openbook > Galileo Computing - Professionelle Bücher. Auch für Einsteiger.
Professionelle Bücher. Auch für Einsteiger

 << zurück
Java ist auch eine Insel von Christian Ullenboom
Programmieren für die Java 2-Plattform in der Version 5
Java ist auch eine Insel

Java ist auch eine Insel
5., akt. und erw. Auflage
1454 S., mit CD, 49,90 Euro
Galileo Computing
ISBN 3-89842-747-1
gp Kapitel 9 Threads und nebenläufige Programmierung
  gp 9.1 Prozesse und Threads
    gp 9.1.1 Wie parallele Programme die Geschwindigkeit steigern können
  gp 9.2 Threads erzeugen
    gp 9.2.1 Threads über die Schnittstelle Runnable implementieren
    gp 9.2.2 Thread mit Runnable starten
    gp 9.2.3 Der Name eines Threads
    gp 9.2.4 Die Klasse Thread erweitern
    gp 9.2.5 Wer bin ich?
  gp 9.3 Der Ausführer (Executor) kommt
    gp 9.3.1 Die Schnittstelle Executor
    gp 9.3.2 Die Thread-Pools
    gp 9.3.3 Threads mit Rückgabe über Callable
    gp 9.3.4 Mehrere Callable abarbeiten
    gp 9.3.5 Mit ScheduledExecutorService wiederholende Ausgaben und Zeitsteuerungen
  gp 9.4 Die Zustände eines Threads
    gp 9.4.1 Threads schlafen
    gp 9.4.2 Das Ende eines Threads
    gp 9.4.3 UncaughtExceptionHandler für unbehandelte Ausnahmen
    gp 9.4.4 Einen Thread höflich mit Interrupt beenden
    gp 9.4.5 Der stop() von außen und die Rettung mit ThreadDeath
    gp 9.4.6 Ein Rendezvous mit join() und Barrier sowie Austausch mit Exchanger
    gp 9.4.7 Mit yield() auf Rechenzeit verzichten
    gp 9.4.8 Arbeit niederlegen und wieder aufnehmen
    gp 9.4.9 Priorität
    gp 9.4.10 Der Thread ist ein Dämon
  gp 9.5 Synchronisation über kritische Abschnitte
    gp 9.5.1 Gemeinsam genutzte Daten
    gp 9.5.2 Probleme beim gemeinsamen Zugriff und kritische Abschnitte
    gp 9.5.3 Punkte parallel initialisieren
    gp 9.5.4 i++ sieht atomar aus, ist es aber nicht
    gp 9.5.5 Kritische Abschnitte schützen
    gp 9.5.6 Schützen mit ReentrantLock
    gp 9.5.7 Synchronisieren mit synchronized
    gp 9.5.8 Synchronized-Methoden der Klasse StringBuffer
    gp 9.5.9 Mit synchronized synchronisierte Blöcke
    gp 9.5.10 Look-Freigabe im Fall von Exceptions
    gp 9.5.11 Mit synchronized nachträglich synchronisieren
    gp 9.5.12 Monitore sind reentrant, gut für die Geschwindigkeit
    gp 9.5.13 Synchronisierte Methodenaufrufe zusammenfassen
    gp 9.5.14 Deadlocks
    gp 9.5.15 Erkennen von Deadlocks
  gp 9.6 Synchronisation über Warten und Benachrichtigen
    gp 9.6.1 Die Schnittstelle Condition
    gp 9.6.2 Beispiel Erzeuger-Verbraucher-Programm
    gp 9.6.3 Warten mit wait() und Aufwecken mit notify()
    gp 9.6.4 Falls der Lock fehlt: IllegalMonitorStateException
    gp 9.6.5 Semaphoren
  gp 9.7 Atomares und frische Werte mit volatile
    gp 9.7.1 Der Modifizierer volatile bei Objekt-/Klassenvariablen
    gp 9.7.2 Das Paket java.util.concurrent.atomic
  gp 9.8 Mit dem Thread verbundene Variablen
    gp 9.8.1 ThreadLocal
    gp 9.8.2 InheritableThreadLocal
  gp 9.9 Gruppen von Threads in einer Thread-Gruppe
    gp 9.9.1 Aktive Threads in der Umgebung
    gp 9.9.2 Etwas über die aktuelle Thread-Gruppe herausfinden
    gp 9.9.3 Threads in einer Thread-Gruppe anlegen
    gp 9.9.4 Methoden von Thread und ThreadGroup im Vergleich
  gp 9.10 Die Klassen Timer und TimerTask
    gp 9.10.1 Job-Scheduler Quartz
  gp 9.11 Einen Abbruch der virtuellen Maschine erkennen


Galileo Computing

9.5 Synchronisation über kritische Abschnitte  downtop

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 werden wir mehr über gemeinsam genutzte Daten und Schutzmaßnahmen beim konkurrierenden Zugriff durch mehrere Threads lernen.


Galileo Computing

9.5.1 Gemeinsam genutzte Daten  downtop

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

class T extends Thread
{
    static   int result;
  public void run() { ... }
}

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.


Galileo Computing

9.5.2 Probleme beim gemeinsamen Zugriff und kritische Abschnitte  downtop

Dass Threads ihre eigenen Daten verwalten – sie haben alle eigene lokale Variablen und einen Stack –, ist kein Anlass zur Sorge, weil sich die Threads gegenseitig nicht in die Quere kommen. Auch wenn mehrere Threads gemeinsame Daten nur lesen, ist 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 für 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 parallel auf diesen Daten zu arbeiten, 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 fertig gestellt hat, darf er den nächsten in Angriff nehmen.

Kritische Abschnitte

Zusammenhängende Programmblöcke, die nicht unterbrochen werden dürfen und 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 wissen, 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. Wir werden uns nun Beispiele für kritische Abschnitte anschauen und dann sehen, wie wir diese in Java realisieren können.


Galileo Computing

9.5.3 Punkte parallel initialisieren  downtop

Nehmen wir an, ein Thread T1 belegt das vorher mit (0,0) belegte Point-Objekt p mit den Werten (1,2) und ein Thread T2 gleichzeitig mit den Werten (2,1). Das bedeutet: T1 führt die Anweisungen

p.x = 1; p.y = 2;

durch und T2 die Anweisungen

p.x = 2; p.y = 1;

Jetzt ist es möglich, dass T1 mit der Arbeit beginnt und x = 1 setzt. T1 wird nun unterbrochen, und T2 kommt an die Reihe. Dieser überschreibt x = 2 und setzt auch y = 1. Jetzt darf T1 weitermachen und vervollständigt y = 2. Wir erkennen das nicht beabsichtigte Ergebnis (2,2), es könnte aber auch (1,1) sein, wenn wir das gleiche Szenario beginnend mit T2 durchführen. Je nach zuerst abgearbeitetem Thread hätten wir jedoch entweder (1,2) oder (2,1) erwartet. Die Threads müssen ihre Arbeit also atomar erledigen, und die Zuweisung bildet einen kritischen Abschnitt, der geschützt werden muss.

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 9.14   ParallelPointInit.java

import java.awt.Point;
public class ParallelPointInit
{
  public static void main( String[] args )
  {
    final Point p = new Point();
    Runnable r = new Runnable()
    {
      public void run()
      {
        int x = (int)(Math.random() * 1000)y = x;
        while ( true )
        {
          p.x = x; p.y = y;            // *
          int xc = p.xyc = p.y;      // *
          if ( xc != yc )
            System.out.println( "Aha: x=" + xc + ", y=" + yc );
        }
      }
    };
    new Thread( r ).start();
    new Thread( r ).start();
  }
}

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!

Aha: x=58y=116
Aha: x=116y=58
Aha: x=58y=116
Aha: x=58y=116
...

Galileo Computing

9.5.4 i++ sieht atomar aus, ist es aber nicht  downtop

Das Beispiel 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 9.15   IPlusPlus.java

public class IPlusPlus
{
  static int i;
  static void foo()
  {
   i++;
  }
}

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 für die Methode foo() an:

0 getstatic #19 <Field int i>
3 iconst_1
4 iadd
5 putstatic #19 <Field int i>
8 return

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:

gp  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.
gp  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.
gp  Jetzt steht in i das von Thread B um 1 erhöhte i. Thread A addiert nun 1 auf den 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 die 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.

Was wir mit den parallelen Punkten und i++ 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 beziehungsweise race hazard (zu Deutsch auch Wettlaufsituation).


Galileo Computing

9.5.5 Kritische Abschnitte schützen  downtop

Soll die Laufzeitumgebung nur einen Thread in einen Block lassen, benötigen wir einen Monitor. Der Begriff geht auf C. A. R. Hoare zurück, der im Aufsatz »Communicating Sequential Processes« von 1978 erstmals dieses Konzept veröffentlichte.

Tritt ein Thread in den kritischen Abschnitt ein, können wir uns vorstellen, dass die virtuelle Maschine die Methode wie eine Tür abschließt. Erst wenn die Methode wieder beendet wird, schließt die JVM die Tür wieder auf und ein anderer Thread kann die Methode betreten. Das Ein- und Austreten wird von der Java-Maschine übernommen, und wir müssen das nicht kontrollieren. Kommt ein zweiter Thread zu der abgeschlossenen Methode (das Objekt war verriegelt), muss er warten und wird erst hineingelassen, wenn die Markierung gelöscht ist. So ist die Abarbeitung über mehrere Threads einfach synchronisiert. Ein anschauliches Alltagsbeispiel ist unschwer zu finden, wenn wir schon einmal bei dem Vergleich mit der Tür sind. Gehen wir aufs Klo, um unsern Job zu machen, schließen wir die Tür hinter uns. Möchte jemand anders auf die Toilette, muss er warten. Es kann sich vor dem Klosett dann eine Schlange bilden. Genauso wartet eine Methode, genauer gesagt ein Thread, wegen eines belegten Objekts auf seinen Eintritt in den synchronisierten Block wie ein Wartender vor dem Klo, auch wenn der auf der Toilette Sitzende nach einer langen Nacht einnickt. Mit dem Abschließen und Aufschließen werden wir uns noch intensiver in den folgenden Abschnitten beschäftigen. Wir werden auch sehen, dass bei synchronisierten Methoden alle Türen des Objekts abgeschlossen werden.

Mit dem Monitor – wir nennen ihn auch Lock (leicht zu merken dank eines Schlüssels, der die Tür abschließt) – ist der serielle Zugriff gewährleistet. Mit dem Konzept wird der Thread vor dem Betreten des kritischen Abschnittes den binären Monitor setzen, und andere ankommende Threads müssen warten, wenn dieser gesetzt ist. Verlässt der Thread den Abschnitt, gibt er den Monitor wieder frei.

Soll ein Programmabschnitt oder eine Objekt- oder Klassenmethode atomar ablaufen, gibt es dafür in Java zwei Möglichkeiten:

gp  Ein Sprachkonstrukt mit dem Schlüsselwort synchronized;
gp  Klassen aus dem Paket java.util.concurrent.lock ermöglichen explizites Locking.

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

p.x = x; p.y = y;
int xc = p.xyc = p.y;

Das Problem ist lösbar, wenn der Zugriff auf den Punkt nur über jeweils einen Thread erfolgt. 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.


Galileo Computing

9.5.6 Schützen mit ReentrantLock  downtop

Seit Java 5 gibt es das Konzept der Locks, mit dem sich ein kritischer Block markieren lässt. Ein Abschnitt wird mit lock() begonnen und mit unlock() beendet.

Listing 9.16   ParallelPointInitSync.java

import java.awt.Point;
  import java.util.concurrent.locks.Lock;
import java.util.concurrent.locks.ReentrantLock;
  public class ParallelPointInitSync
{
  public static void main( String[] args )
  {
      final Lock lock = new ReentrantLock();
      final Point p = new Point();
    Runnable r = new Runnable()
    {
      public void run()
      {
        int x = (int)(Math.random() * 1000)y = x;
        while ( true )
        {
            lock.lock();
            p.x = x; p.y = y;            // *
          int xc = p.xyc = p.y;      // *
            lock.unlock();
            if ( xc != yc )
            System.out.println( "Aha: x=" + xc + ", y=" + yc );
        }
      }
    };
    new Thread( r ).start();
    new Thread( r ).start();
  }
}

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.


interface java.util.concurrent.locks.Lock

gp  void lock() Wartet so lange, bis der kritische Abschnitt betreten werden kann, und markiert ihn dann als betreten.
gp  boolean tryLock() Wenn der kritische Abschnitt sofort betreten werden kann, ist die Funktionalität wie lock() und die Rückgabe true. Ist der Lock gesetzt, so wartet die Methode nicht wie lock(), sondern kehrt mit einem false zurück.
gp  boolean tryLock( long time, TimeUnit unit ) throws InterruptedException Wartet eine Zeit lang auf den Lock wie tryLock(). Das Warten kann unterbrochen werden, was die Methode mit einer Exception beendet.
gp  void unlock() Verlässt den kritischen Block.
gp  void lockInterruptibly() throws InterruptedException Ermöglicht das Warten auf den Zutriff mit interrupt() vom wartenden Thread zu unterbrechen. Der lock()-Methode ist ein Interrupt egal. Implementierende Klassen der Schnittstelle müssen diese Operation nicht zwingend anbieten.

Beispiel   Wenn wir sofort in den kritischen Abschnitt können, machen wir das; sonst etwas anders.
Lock lock = ...;
if (   lock.tryLock()   )
{
  try {
    ...
  }
  finally { lock.unlock(); }
}
else
  ...

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


class java.util.concurrent.locks.ReentrantLock implements Lock, Serializable

gp  ReentrantLock() Erzeugt ein neues Lock-Objekt, welches nicht den am längsten Wartenden den ersten Zugriff gibt.
gp  ReentrantLock( boolean fair ) Erzeugt ein neues Lock-Objekt mit fairem Zugriff, gibt also dem längsten Wartenden den ersten Zugriff.
gp  boolean isLocked() Anfrage, ob der Lock gerade genutzt wird und im Moment kein Betreten möglich ist.
gp  int getHoldCount() Wie viele auf das Betreten des Blockes warten.

Beispiel   Das Warten auf den Lock kann unterbrochen werden.
Lock l = new ReentrantLock();
try {
    l.lockInterruptibly();
    try {
   ...
  }
  finally { l.unlock();}
}
catch ( InterruptedException e ) { ... }
Ohne den Lock bekommen zu haben, dürfen wir ihn auch nicht freigeben!

ReentrantReadWriteLock

Unsere 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:

ReentrantReadWriteLock lock = new ReentrantReadWriteLock();
try {
  lock.readLock().lock();
  ...
} finally {
  lock.readLock().unlock();
}

Eine Assoziativspeicher ist eine Datenstruktur, die ein Objekt mit einem beliebigen anderen verbinden kann. HashMap ist eine Java-Klasse, die über put() eine Assoziation erreicht und über get() erfragt. Wir wollen nun über ReentrantReadWriteLock die Leseoperationen parallel ermöglichen, aber Schreiboperationen atomar ausführen.

Listing 9.17   ParallelMap.java

import java.util.*;
import java.util.concurrent.locks.*;
public class ParallelMap<K,V>
{
  private final HashMap<KV>  map = new HashMap<K,V>();
  private final ReadWriteLock lock = new ReentrantReadWriteLock();
  private final Lock      readLock = lock.readLock()writeLock = lock.writeLock();
  public V get( K key )
  {
    readLock.lock();
    try {
      return map.get( key );
    }
    finally {
      readLock.unlock();
    }
  }
  public V put( K keyV value )
  {
    writeLock.lock();
    try {
      return map.put( keyvalue );
    }
    finally {
      writeLock.unlock();
    }
  }
  public void clear()
  {
    writeLock.lock();
    try {
      map.clear();
    }
    finally {
      writeLock.unlock(); }
  }
}

Galileo Computing

9.5.7 Synchronisieren mit synchronized  downtop

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

Betritt die JVM die synchronisierte Methode, wird so lange gewartet, bis der Lock frei ist und dann die Methode betreten und abgeschlossen wird. Nach dem Verlassen wird der Lock wieder freigegeben. Damit hängt die Dauer des Locks mit der Dauer des Methodenaufrufs zusammen. Eine Endlosschleife in der synchronisierten Methode würde den Lock niemals freigeben.

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

synchronized void foo() { i++; }

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 parallel 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 später vorgestellt.

Eclipse

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.

Abbildung
Hier klicken, um das Bild zu Vergrößern

Hat der aktuelle Thread den Lock?

Die statische Funktion Thread.holdsLock() zeigt an, ob der aktuelle Thread den Lock nutzt.

Listing 9.18   HoldsLockDemo.java, main()

final Object obj = new Object();
System.out.println( Thread.holdsLock(obj) );     // false
synchronized ( obj )
{
  System.out.println( Thread.holdsLock(obj) );   // true
}

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.

Dann machen wir doch gleich alles synchronized ...

In nebenläufigen Programmen kann es schnell zu unerwünschten Nebeneffekten kommen. Das ist auch der Grund, warum Thread-lastige Programme schwer dezubuggen 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.

gp  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 viel teurer.
gp  Zusätzlich kommt als Problem hinzu, wenn eine nicht notwendigerweise, also überflüssige, 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. Das synchronized macht die Vorteile von Mehrprozessormaschinen zunichte.
gp  Wenn alle Methoden synchronisiert sind, steigt auch die Gefahr eines unnötigen Deadlocks. In den folgenden Abschnitten erfahren wir etwas mehr über Deadlocks.

Galileo Computing

9.5.8 Synchronized-Methoden der Klasse StringBuffer  downtop

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

public synchronized char charAt( int index )
{
  if ( (index < 0) || (index >= count) )
    throw new StringIndexOutOfBoundsException( index );
  return value[index];
}

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 kann es zum Beispiel dadurch geben, dass ein Thread gerade den String verkleinert und gleichzeitig charAt() aufgerufen wird. Und 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.


Beispiel   Das StringBuffer-Objekt sb1 wird von zwei Threads T1 und T2 bearbeitet, indem synchronisierte Methoden genutzt werden. Bearbeitet Thread T1 den StringBuffer sb1 mit einer synchronisierten Methode, dann kann T2 erst dann eine synchronisierte Methode für sb1 aufrufen, wenn T1 die Methode abgearbeitet hat. Denn T1 setzt bei sb1 die Sperre, die T2 warten lässt. Gleichzeitig kann aber T2 synchronisierte Methoden für ein anderes StringBuffer-Objekt sb2 aufrufen, da sb2 einen eigenen Monitor besitzt. Das macht noch einmal deutlich, dass die Locks zu einem Objekt gehören und nicht zur synchronisierten Methode.


Galileo Computing

9.5.9 Mit synchronized synchronisierte Blöcke  downtop

Wenn wir mit Lock-Objekten arbeiten, können wir den Block so fein wählen, wie erforderlich ist. Mit synchronized haben wir bisher nur eine gesamte Methode sperren können, was in machen 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:

  synchronized (   objektMitDemMonitor   )
  {
  ...
}

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, dass über einen beliebigen Monitor synchronisiert werden kann und nicht unbedingt über den Monitor des Objekts, für das die synchronisierte Methode aufgerufen wurde, wie es bei synchronisierten Objektmethoden üblich ist.


Hinweis   Eine synchronisierte Objektmethode ist nichts anderes als eine Variante von:
  synchronized( this )
  {
  // Code der Methode.
}

Statisch synchronisierte Blöcke

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

Listing 9.19   StaticSync.java

class StaticSync
{
  private static final Object o = new Object();
  static void staticFoo()
  {
     synchronized( o )
     {
       // ...
     }
  }
}

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, stellt sich die Frage erst gar nicht.


Hinweis   Bei Lock-Objekten oder synchronized-Blöcken kann der zwingend synchronisierbare Teil in einem kleinen Abschnitt bleiben. Die JVM kann die anderen Teile parallel abarbeiten, und andere Threads dürfen die anderen Teile betreten. Als Resultat ergibt sich eine verbesserte Geschwindigkeit.


Galileo Computing

9.5.10 Look-Freigabe im Fall von Exceptions  downtop

Kommt es innerhalb eines synchronized Blocks beziehungsweise 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 9.20   UnlockInFinally.java, main()

ReentrantLock lock = new ReentrantLock();
try
{
  lock.lock();
  System.out.println( lock.getHoldCount() ); // 1
  try
  {
    System.out.println( 12 / 0 );
  }
    finally
  {
    lock.unlock();
  }
  }
catch ( Exception e )
{
  System.out.println( e.getMessage() );    // / by zero
}
System.out.println( lock.getHoldCount() ); // 0

Nach dem lock() liefert getHoldCount() eins, 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 null, da finally das unlock() ausführte. Würden wir die Zeile mit unlock() auskommentieren, würde getHoldCount() weiterhin eins liefern, was ein Fehler ist.


Galileo Computing

9.5.11 Mit synchronized nachträglich synchronisieren  downtop

Obwohl viele Java-Funktionen in der Standardbibliothek synchronisiert sind, gibt es immer noch einige Methoden, bei denen die Entwickler auf eine Synchronisierung verzichtet haben – etwa setLocation() bei Point. 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 wenn keine Parallelität üblich ist, warum bezahlen für das, was keiner bestellt hat?

Im ersten motivierenden Beispiel haben wir die Initialisierung eines Point-Objekts betrachtet. Dass der Zugriff auf zwei Variablen nicht atomar sein kann, ist klar. Auch die Nicht-synchronisiert-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 zwei Dinge andenken:

gp  Wir verwenden ein Lock-Objekt, das allen Threads zugänglich ist. Das Objekt nutzten sie zur Synchronisation.
gp  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:

Point p = new Point();
  synchronized( p )
  {
  p.setLocation( 12 );
}

Auf diese Weise kann jeder Aufruf einer nicht synchronisierten 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.


Galileo Computing

9.5.12 Monitore sind reentrant, gut für die Geschwindigkeidowntop

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, dann 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 Parallelität, da der kritische Abschnitt künstlich vergrößert wird. Die Technik kann geschwindigkeitssteigernd sein, wenn viele synchronisierte Methoden hintereinander aufgerufen werden.


Beispiel   In StringBuffer sind viele Methoden synchronisiert. Das heißt, dass bei jedem Aufruf einer Methode der Monitor reserviert werden muss. Das kostet natürlich eine Kleinigkeit, und als Lösung bietet sich an, die Aufrufe in einem eigenen synchronisierten Block zu bündeln.
StringBuffer sb = new StringBuffer();
  synchronized( sb )
{
    sb.append( "Transpirations-" );
  sb.append( "Illustration" );
  sb.append( "\t" );
  sb.append( "Röstreizstoffe" );
  }  
Wir können uns vorstellen, dass bei der Klasse ein kleiner Zähler ist, der bei jedem Betreten inkrementiert und beim Verlassen dekrementiert wird. Ist der Zähler null, befindet sich kein Thread im Block. Ist er größer null, haben wir einen reentranten Zugriff.

Die Klasse ReentrantLock verwaltet den Zähler – er geht bis 2^31 – 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 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 aber 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.


Galileo Computing

9.5.13 Synchronisierte Methodenaufrufe zusammenfassen  downtop

Synchronisierte Methoden stellen sicher, dass bei mehreren parallel 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 parallelen 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?

for ( char c = 'a'; c <= 'z'; c++ )
  sb.append( c );

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.

synchronized ( sb )
{
  for ( char c = 'a'; c <= 'z'; c++ )
    sb.append( c );
}

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

Das Beispiel zeigt, wie gut sich ein sychronized 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 ein zweiter Thread sich 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() Blockes eintreten.


Galileo Computing

9.5.14 Deadlocks  downtop

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. Dieser Thread B belegt aber eine Ressource, die A gerne bekommen 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.

Abbildung
Hier klicken, um das Bild zu Vergrößern


Beispiel   Zwei Threads schlagen sich um die Objekte a und b. Dabei kommt es zu einem Deadlock, da sie einen Lock besetzen, den der jeweils andere zum Weiterarbeiten benötigt.

Listing 9.21   Deadlock.java

class Deadlock
{
  static final Object a = new Object(),
                      b = new Object();
  static class T1 extends Thread
  {
    @Override
    public void run()
    {
      synchronized( a ) {
        System.out.println( "T1: Lock auf a bekommen" );
        warte();
        synchronized( b ) {
          System.out.println( "T1: Lock auf b bekommen" );
        }
      }
    }
    private void warte() {
      try {
        Thread.sleep( 1000 );
      } catch ( InterruptedException e ) { e.printStackTrace(); }
    }
  }
  static class T2 extends Thread
  {
    @Override
    public void run()
    {
      synchronized( b ) {
        System.out.println( "T2: Lock auf b bekommen" );
        synchronized( a ) {
          System.out.println( "T2: Lock auf a bekommen" );
        }
      }
    }
  }
  public static void main( String[] args )
  {
    new T1().start();
    new T2().start();
  }
}

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

T1: Lock auf a bekommen
T2: Lock auf b bekommen

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 a, dann b. Bei unbekannten, dynamisch wechselnden Objekten muss dann unter Umständen eine willkürliche Ordnung festgelegt werden.


Galileo Computing

9.5.15 Erkennen von Deadlocks  toptop

Die Sun JVM verfügt über eine eingebaute Deadlock-Erkennung, die auf der Konsole aktiviert werden kann. Dazu ist unter Windows die Tastenkombination (Crtl)-(Break) zu drücken und unter Linux oder Solaris (Crtl)+(\). Für das obige Programm ergibt sich unter den letzten Ausgabezeilen:

Java stack information for the threads listed above:
===================================================
"Thread-2":
        at Deadlock$T2.run(Deadlock.java:36)
        – waiting to lock <02A2F0E8> (a java.lang.Object)
        – locked <02A2F0F0> (a java.lang.Object)
"Thread-1":
        at Deadlock$T1.run(Deadlock.java:16)
        – waiting to lock <02A2F0F0> (a java.lang.Object)
        – locked <02A2F0E8> (a java.lang.Object)
Found 1 deadlock.

Das ist genau die Meldung, die bei gegenseitigem Blockieren hilft. Zwar findet das Tool nicht alle Deadlocks, insbesondere nicht die, in denen Threads mit wait() auf Monitore warten, sonst aber kann es insbesondere bei grafischen Programmen eine gute Hilfe sein.




1  Machbar zum Beispiel mit dem jeder Java-Distribution beiliegenden Dienstprogramm javap-c.

 << zurück




Copyright © Galileo Press GmbH 2005
Für Ihren privaten Gebrauch dürfen Sie die Online-Version natürlich ausdrucken. Ansonsten unterliegt das <openbook> denselben Bestimmungen, wie die gebundene Ausgabe: Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen.


[Galileo Computing]

Galileo Press GmbH, Rheinwerkallee 4, 53227 Bonn, Tel.: 0228.42150.0, Fax 0228.42150.77, info@galileo-press.de