In unserem letzten Artikel / KRE3 / haben wir uns angesehen, wie ein Thread durch Aufruf der Methode Object.wait() auf das Eintreten einer logischen Bedingung warten kann, die ihm ein anderer Thread durch Aufruf der Methode Object.notify() oder Object.notifyAll() signalisiert. Dabei haben wir für das Warten und Signalisieren mehrerer logischer Bedingungen immer nur ein einziges Bedingungsobjekt verwendet. In diesem Artikel wollen wir uns ansehen, warum man das so macht bzw. warum die Verwendung mehrerer Bedingungsobjekte bei der Benutzung von wait() und notify() (bzw notifyAll()) in der Regel zu Problemen (dem sogenannten Nested-Monitor-Problem) führt. Am Ende des Artikel schauen wir uns dann noch an, wie die Neuerungen im JDK 1.5 dazu führen, dass das bisherige Standardvorgehen bei der Benutzung von Bedingungen in Java sich geändert hat.
 

Rückblick: der BlockingIntStack

public class BlockingIntStack {
 private final int[] array;
 private volatile int cnt = 0;

 public IntStack (int sz) { array = new int[sz]; }

synchronized public void push (int elm) throws InterruptedException {
   while (cnt == array.length)
     wait();
   if (cnt == 0)
     notifyAll();
   array[cnt++] = elm;
 }

 synchronized public int pop () throws InterruptedException {
   while (cnt == 0)
     wait();
   if (cnt == array.length)
     notifyAll();
   return(array[--cnt]);
 }

 public int size() { return cnt; }

 public int capacity() { return (array.length); }

}

Das Objekt auf dem wait() und notifyAll() aufgerufen wird, ist in der obigen Implementierung immer dasselbe, nämlich this. Dies gilt sowohl für das Warten und Notifizieren bei einem vollen wie auch bei einem leeren Stack. Das Objekt, das für das Warten/Notifizieren genutzt wird, nennt man in Anlehnung an Thread APIs, die vor Java existiert haben, Bedingung (englisch: condition). Das heißt, in unserer Implementierung werden die zwei logischen Bedingungen: ‚nicht mehr voll’ und ‚nicht mehr leer’ an einem einzigen Bedingungsobjekt (nämlich this) kommuniziert.

Ein einziges Bedingungsobjekt für verschiedene logische Bedingungen zu verwenden ist recht typisch für die Benutzung von wait() und notify() (bzw notifyAll()) in Java. Warum das so ist, bzw. warum das in den meisten Fällen sogar so sein muss, wollen wir in diesem Artikel untersuchen.
 

Das Nested-Monitor-Problem

public class BlockingIntStackWithTwoCondtions {
 private final Object fullCondition = new Object();
 private final Object emptyCondition = new Object();

 private final int[] array;
 private volatile int cnt = 0;

 public IntStack (int sz) { array = new int[sz]; }

 public int size() { return cnt; }

 public int capacity() { return (array.length); }
}

Eine mögliche Implementierung von push() und pop(), die diesen Anforderungen gerecht wird, sieht folgendermaßen aus:

public void push (int elm) throws InterruptedException {
 synchronized(fullCondition) {
  synchronized(emptyCondition) {
   while (cnt == array.length)
     fullConnection.wait();
   if (cnt == 0)
     emptyConnection.notifyAll();
   array[cnt++] = elm;
  }
 }
}

public int pop () throws InterruptedException {
 synchronized(fullCondition) {
  synchronized(emptyCondition) {
   while (cnt == 0)
     emptyConnection.wait();
   if (cnt == array.length)
     fullConnection.notifyAll();
   return(array[--cnt]);
  }
 }
}

Bevor wir diese Gründe im Detail diskutieren, erinnern wir uns noch einmal daran, was wir über das Zusammenspiel von wait() und notify() (bzw. notifyAll()) in unserem letzten Artikel gesagt haben: der Thread gibt implizit das Mutex des Bedingungsobjekts frei, wenn er wait() darauf aufruft. Dies ist auch unbedingt nötig, damit der Thread, der notify() (bzw. notifyAll()) aufrufen möchte, das Mutex sperren kann, um danach notify() (bzw. notifyAll()) aufrufen zu können. Detaillierter kann man dies im Sequenzdiagram in Abbildung 1 sehen. Es zeigt einen Produzenten-Thread, der an einem vollen BlockingIntStack (mit nur einer Bedingung) darauf wartet, dass ein Konsumenten-Thread einen Wert herausnimmt.

Abbildung 1: Synchronisation über wait() und notifyAll() unter Verwendung von nur einem Bedingungsobjekt

Funktioniert diese Synchronisation in der gleichen Situation mit unserem BlockingIntStackWithTwoConditions? Nein, leider nicht. Der Produzenten-Thread sperrt erst das fullCondition Mutex und dann das emptyCondition Mutex. Da der Stack bereits voll ist, kommt er in die while-Schleife und ruft fullCondition.wait() auf. Damit gibt der das fullCondition Mutex frei. Man beachte: er hält weiterhin das emptyCondition Mutex. Ruft nun der Konsumenten-Thread pop(), so versucht er nacheinander das fullCondition Mutex und dann das emptyCondition Mutex zu sperren. Beim emptyCondition Mutex bleibt er hängen, weil dies noch dem Produzenten-Thread gehört. Dies ist dann auch der vollständige Stillstand dieses aus Produzenten und Konsumenten bestehenden Systems. Abbildung 2 zeigt diesen Ablauf in einem Sequenzdiagram.

Das gerade beschriebene Problem ist eine wohlbekannte Tatsache in der Java-Multithread-Programmierung - eine Art Anti-Pattern mit dem Namen Geschachtelter-Monitor-Problem (englisch: nested monitor problem).

Skeptiker zweifeln an dieser Stelle vielleicht daran, dass die obige Implementierung von push() und pop() bzgl. des Problems repräsentativ ist. Schließlich gibt es ein ganze Reihe von Variationsmöglichkeiten und darunter könnte ja eine sein, die dieses Problem nicht hat und außerdem noch korrekt ist. Trotzdem gibt es keine Lösung. Wie man es auch dreht und wendet, das Nested-Monitor-Problem läuft im Prinzip immer darauf hinaus, dass beim Aufruf von wait() nur das Mutex desjenigen Bedingungsobjekts frei gegeben wird, auf  dem wait() aufgerufen wird. Wenn aber mehrere Bedingungsobjekte verwendet werden, dann werden  immer auch mehrere Mutexe gehalten; das liegt an der in Java (pre-JDK 1.5) eingebauten 1:1-Beziehung zwischen Bedingung und Mutex, bei der jedes Bedingungsobjekt immer genau das eigene Mutex verwendet. Das Problem läßt sich vermeiden, wenn man mit nur einem Bedingungsobjekt (und seinem Mutex) arbeitet und daran zwei logische Bedingungen kommuniziert werden. Womit wir wieder beim BlockingIntStack vom Anfang wären.

Abweichend von unserer Implementierung  des BlockingIntStack mit einem Bedingungsobjekt ist es natürlich möglich, als Bedingungsobjekt nicht this sondern ein explizites privates Attribut zu verwenden. Die Vor- bzw. Nachteile bei der Benutzung eines expliziten privaten Bedingungsobjekts sind im wesentlichen die gleichen wie die bei der Benutzung eines expliziten privaten Mutexobjekt. Wir haben diese Situation bereits in einem der vorhergehenden Artikel (siehe / KRE2 /) diskutiert.
 

Das Nested-Monitor-Problem in der Java-Programmierpraxis

Das ist in der Praxis nicht immer so einfach. Betrachten wir eine andere Situation. Nehmen wir zum Beispiel eine Klasse A, deren Methoden mit dem Mutex von this synchronisiert sind. Diese Klasse enthält ein Attribut der Klasse B, die als Bedingungsobjekt wieder this (aber diesmal das des Attributs vom Typ B) nutzt.
 

public class A {   private B b;   public synchronized void m1() {      ...     b.m3();      ...   }   public synchronized void m2() {      ...     b.m4();      ...   } }

public class B {   public synchronized void m3() {      ...      while (...)        wait();      ...   }   public synchronized void m4() {      ...     if (...)       notifyAll();      ...   } }

Hier haben wir ebenfalls einen geschachtelten Monitor, wenn die synchronisierten Methoden der äußeren Klasse A die Methoden aus B aufrufen, die ihrerseits wait() und notify() (oder notifyAll()) aufrufen.  Das Sequenzdiagramm in Abbildung 3 zeigt den Ablauf.  Es wird zwar nur eine logische Bedingung verwendet (in der Klasse B), aber es werden zwei Monitore (nämlich der des äußeren A -Objekts und der des enthaltenen B -Objekts) benutzt.  Der Aufruf von wait() in der Klasse B gibt nur das Mutex von B frei, aber der andere Thread wartet noch immer auf das Mutex von A und wird niemals dazu kommen, eine Methode von B aufzurufen, die die erwartete Zustandsänderung herbeiführen könnte.  Wir haben also wieder ein Nested-Monitor-Problem.

Zusammenfassung

Dabei sind diverse Details zu beachten. Wir haben den Unterschied zwischen notify() und  notifyAll() diskutiert. Dabei hat sich herausgestellt, dass die robusteste Art der Verwendung von wait() und notify() darin besteht, in einer while-Schleife den Zustand abzufragen und danach per wait() zu warten, während der signalisierende Thread die Benachrichtigung per notifyAll() an alle wartenden Threads (und nicht per notify() an nur genau einen Thread) versendet.

Abbildung 3: Nested-Monitor-Problem bei Verwendung von zwei Mutexen

Eine getrennte statische Analyse der beiden Klassen A und B enthüllt das Problem allerdings nicht, da das Thread-Verhalten von dem dynamischen Ablauf (welche Mutexe wurden wann gesperrt?) und weniger von der statischen Struktur innerhalb der einzelnen Klasse abhängt. Dies ist ein Beispiel dafür, dass die Ideen der Objektorientierung (Datenkapselung in Abstraktionen, Polymorphismus in Klassenhierarchien, etc.) und die Ideen der Multithread-Welt eher orthogonal zueinander stehen, als sich zu ergänzen. Verwirrend ist dabei, dass in Java im Vergleich zu anderen Programmiersprachen die statische Struktur innerhalb einer Klasse noch eine relativ große Rolle spielt, da Sperren ausschließlich an Block- bzw. Methodengrenzen aktiviert und deaktiviert werden können (zumindest bis zum JDK 1.5).

Wenn also die statische Analyse eines Nested-Monitor-Problems relativ mühselig ist und eine gewisse Erfahrung mit der Multithread-Programmierung voraussetzt, stellt sich automatisch die Frage, ob es andere Möglichkeiten der Fehleranalyse gibt. Verschiedene Tools (siehe Randbemerkun g "Hilfsmittel für die Deadlock-Analyse") bieten die Möglichkeit, sich die von einem Thread gesperrten Mutexe sowie die Gründe für das Warten eines Threads (Warten auf Mutex-Sperren, Warten an einer Bedinung, usw.) anzusehen. Das heißt, wenn es einen "Hänger" auf Grund eines geschachtelten Monitors gibt, dann kann man sich die wartenden Threads und die von ihnen eventuell gehaltenen Sperren sowie die Gründe für ihr Warten ansehen. Bei richtiger Zuordnung dieser Informationen und dem Wissen darüber, welcher der wartenden Threads potenziell notify() bzw. notifyAll() auf der fraglichen Bedingung aufgerufen haben könnte, lassen sich dann meist die Ursachen für den “Hänger“ finden.

Obwohl Tools, mit denen man sich die Sperren eines Threads ansehen kann, meist auch die Fähigkeit haben, Deadlocks selbständig zu finden, ist die manuelle Analyse im Fall eines Nested-Monitor-Problems unumgänglich. Denn ein geschachtelter Monitor ist im eigentlichen Sinne kein echter Deadlock. Bei einem echten Deadlock wartet ein Thread auf die Freigabe einer Sperre (englisch: lock), die von einem anderen Threads gehalten wird, aber nicht mehr freigegeben wird, weil dieser andere Thread seinerseits auf den ersten Thread wartet. Beim geschachtelten Monitor ist die Situation etwas anders: der Thread, der wait() aufgerufen hat, wartet auf keine Sperre, sondern auf ein Signal, dass ein anderer Thread per notify() oder notifyAll() senden müßte. Es ist in der Regel notwendig, den Sourcecode manuell zu analysieren, um zu erkennen, welcher andere Thread potenziell in der Lage wäre, notify() oder notifyAll() auf der entsprechenden Bedingung aufzurufen. Es reicht nicht aus, lediglich die Sperren zu analysieren.

Und was macht man, wenn man bei der Fehleranalyse festgestellt hat, dass der Grund für den Fehler ein geschachtelter Monitor ist? Man wird versuchen, an beiden Stellen nur ein Mutex- bzw. Bedingungsobjekt zu nutzen. Schauen wir uns das Beispiel mit den Klassen A und B noch einmal an. Dort waren das Mutex- bzw. Bedingungsobjekt das this des Objekts vom Typ A und das this des Attributs b vom Typ B. Eine Lösung könnte so aussehen, dass wir das this des Objekts vom Typ A in beiden Fällen als Mutex- bzw. Bedingungsobjekt nutzten. Das bedeutet, das die Klasse B kein hardcodiertes Mutex- bzw. Bedingungsobjekt mehr nutzen darf, sondern dieses als Parameter im Konstruktor übergeben bekommt. Das Codefragment einer solchen Lösung sähe so aus:
 

public class A {   private B b = new B(this);   public synchronized void m1() {      ...     b.m3();      ...   }   public synchronized void m2() {      ...     b.m4();      ...   } }

public class B {   Object myMutex;   public B(Object mutex) {     myMutex = mutex   }   public void m3() {     synchronized (myMutex) {        ...        while (...)          myMutex.wait();        ...     }   }   public void m4() {     synchronized (myMutex) {        ...       if (...)         myMutex.notifyAll();        ...     }   } }

In der Praxis ist es leider so, dass die Voraussetzungen für die Beseitigung des Nested-Monitor-Problems häufig gar nicht gegeben sind. Dazu müssten Klassen so aussehen wie die Klasse B in unserem Beispiel: sie dürften kein hardcodiertes Mutex- bzw. Bedingungsobjekt verwenden, sondern müßten wir oben gezeigt in der Lage sein, ein beliebiges von Außen übergebenes Mutex- bzw. Bedingungsobjekt benutzen. Schaut man sich aber existierende Klassen an, beispielsweise die Klassen des JDK an, die Synchronisation benutzen, so stellt man fest, dass sie hardcodierte Mutex- bzw. Bedingungsobjekte verwenden. Diese wenig flexible Implementierungstechnik wird im allgemeinen auch bei benutzerdefinierten Klassen verwendet, was letztendlich dazu führt, dass man in der Regel Zugriff auf den Sourcecode der beteiligten Klassen haben muss, um ein bereits identifiziertes Nested-Monitor-Problem zu korrigieren.
 

JDK 1.5 und das Nested-Monitor-Problem

Ein Grund für die Erweiterung des Multithread-API im JDK 1.5 war unter anderem die Absicht, den Java API näher an einen wesentlichen Multithread-API Standard zu bringen, den es bei der Benutzung von C und C++ Programmen gibt: Posix Threads oder kurz P-Threads (siehe / POSIX /). Bei P-Threads ist es möglich, anders als bisher in Java, dass man mehrere Bedingungen mit einem Mutex verbindet. Das wird mit dem JDK 1.5 auch in Java möglich werden. Das heißt, es ist dann möglich, mehrere Bedingungsobjekte zu einem einzigen Mutex zu haben. Damit kann man dann auch einen BlockingIntStackWithTwoCondtions korrekt implementieren.

Bevor wir das machen, schauen wir uns die Details aus dem JDK 1.5 API an. Die Verbindung von mehreren Bedingungsobjekten mit einem Mutex läßt sich mit expliziten Sperren und Bedingugen erreichen. Die expliziten Sperren haben wir bereits in / KRE3 / besprochen.  Sehen wir uns an dieser Stelle die expliziten Bedingungen an. Im Package java.util.concurrent.locks, das neu im JDK 1.5 hinzukommen ist, gibt es ein Interface Condition, das die Funktionalität unterstützt, die man von einer Bedingung im Multithread-Kontext erwartet. Die Methoden des Interfaces Condition sind:

• await() - das entspricht der Funktionalität des Object.wait() wie wir es in diesem und dem vorhergehenden Artikel diskutiert haben.
• awaitNanos(long timeout) - das entspricht der Funktionalität des Object.wait() mit Timeout. Der Timeoutwert ist jetzt aber in Nanosekunden; bei Object.wait() sind es Millisekunden.
• awaitUntil(Date deadline) - das entspricht der Funktionalität des Object.wait() mit Timeout, mit dem Unterschied,  dass ein Objekt vom Typ Date den Timeout-Zeitpunkt beschreibt
• awaitUninterruptibly() - das entspricht der Funktionalität des Object.wait() ohne Timeout, mit dem Unterschied,  dass keine InterruptedException geworfen wird.
• signal() und signalAll() - entsprechen von der Funktionalität her Object.notify()und Object.notifyAll().

Es gibt im neuen Package java.util.concurrent.locks allerdings keine Klasse, die das neuen Interface Condition implementiert.  Es stellt sich daher die Frage: woher bekommt man ein Bedingungsobjekt?  Offensichtlich nicht durch den Aufruf eines Konstruktors irgendeiner Klasse, die das Interface Condition implementiert. Stattdessen werden explizite Bedingungen über explizite Sperren erzeugt.  Da Bedingungsobjekte immer mit einem Mutex verbunden sein müssen, stellen die expliziten Sperren eine Factory-Methode für Bedingungsobjekte zur Verfügung.  Das Interface Lock im Package java.util.concurrent.locks hat eine Methode newCondition(), die ein Bedingungsobjekt liefert.

public Condition newCondition();

Mit diesem Hilfsmittel und unter Berücksichtigung der vorhergehenden Überlegungen zum Nested-Monitor-Problem können wir den BlockingIntStackWithTwoCondtions_JDK_1_5 folgendermaßen implementieren:

public class BlockingIntStackWithTwoCondtions_JDK_1_5 {
 private Lock lock = new ReentrantLock();
 private Condition fullCon  = Locks.newCondition(lock);
 private Condition emptyCon = Locks.newCondition(lock);

 private final int[] array;
 private volatile int cnt = 0;

 public void push(int element) {
    lock.lock();
    try {
      while (cnt == size) {
        try { fullCon.await(); } catch (InterruptedException e) {...}
      }
      array[cnt++] = element;
      emptyCon.signal();
    } finally { lock.unlock(); }
 }

 public int pop() {
    lock.lock();
    try {
      while (cnt == 0) {
        try { emptyCon.await(); }
        catch (InterruptedException e) { ... }
      }
      int tmp = array[--cnt];
      fullCon.signal();
      return (tmp);
    } finally { lock.unlock(); }
 }

 public IntStack (int sz) { array = new int[sz]; }

 public int size() { return cnt; }

 public int capacity() { return (array.length); }
}

Trotz der neuen expliziten Bedingungsobjekte kann man natürlich immer noch Probleme in Form von geschachtelten Monitoren und Deadlocks produzieren. Es ist nach wie vor wichtig zu verstehen, wie viele Monitore verwendet werden bzw. dafür zu sorgen, dass immer nur ein Mutex gesperrt und entsperrt wird und verschiedene Bedingungsobjekte gemeinsam dasselbe Mutex verwenden müssen, um Probleme zu vermeiden. In unserer Implementierung oben tun wir das auch: beide Bedingungsobjekte fullCondition und emptyCondition sind an das eine Mutex der expliziten Sperre lock gekoppelt.  In anderen Situationen, wie wir sie am Beispiel der Klassen A und B diskutiert haben, ändert sich auch unter Verwendung von JDK 1.5 nichts.  Im Beispiel der Klassen A und B hatten wir ohnehin nur eine einzige Bedingung verwendet und das Problem lag in der Verwendung von zwei Mutexen.  Die neuen Abstraktionen des JKD 1.5 helfen in solchen Situationen nicht. Man muß immer noch analysieren und verstehen, welche Mutexe verwendet werden und dafür sorgen, dass nur ein Mutex gemeinsam verwendet wird. Wie das im Falle der Klassen A und B geht, haben wir ja schon gezeigt.

Zusammenfassung

Randbemerkung "Hilfsmittel für die Deadlock-Analyse"

Für die Deadlock-Analyse stehen verschiedene Hilfsmittel zur Verfügung: Debugger, JVM-Output, Profiler und Management Beans. Darüber hinaus haben einige der in Java 1.5 neuen Klassen selbst bereits Methoden für das Monitoring. Wir wollen an dieser Stelle nicht erschöpfend auf all diese Hilfsmittel eingehen, sondern nur kurz darauf hinweisen, dass es sie gibt und dass sie u.U. nützlich sein können bei der Suche nach der Ursache für einen "Hänger". Debugger Die meisten Debugger können anzeigen, welche Threads in welchem Zustand sind und ob ein Thread auf einen Mutex wartet oder einen Mutex hält oder auf ein Signal an einer Condition wartet. Selbständige Deadlock-Analyse durch den Debugger ist ebenfalls möglich, wird aber nicht von allen Debuggern gemacht. JVM-Output Die virtuellen Maschinen haben in der Regel einen Mechanismus, mit dem man sich Diagnose-Output ausgeben lassen kann.  Bei der JVM von Sun kann man diesen Output erzeugen, wenn man während des Programmablaufs eine bestimmte Tastenkombination drückt: <ctrl> + <\> auf Linux und Solaris und <ctrl> + <break> auf Windows. Die virtuelle Maschine gibt dann einen Stack-Dump aus, in dem sich unter anderem Information über die Threads und deren Wartezustände findet. Hier ist ein Beispiel: "pool-1-thread-1" prio=5 tid=0x008ef7d0 nid=0xdb8 runnable [0x0144f000..0x0144fae8]         at booth.WorkLoad.work(WorkLoad.java:12)         at booth.Shoppers$Shopper.checkout(Shoppers.java:55)         at booth.Shoppers$Shopper.run(Shoppers.java:61)         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)         at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)         at java.lang.Thread.run(Unknown Source) "main" prio=5 tid=0x00036c38 nid=0x980 in Object.wait() [0x0007f000..0x0007fc3c]         at java.lang.Object.wait(Native Method)         - waiting on <0x629e91b0> (a java.lang.Thread)         at java.lang.Thread.join(Unknown Source)         - locked <0x629e91b0> (a java.lang.Thread)         at java.lang.Thread.join(Unknown Source)         at booth.CheckoutSimulation.main(CheckoutSimulation.java:47) Dabei ist die JVM auch in der Lage, Deadlocks zu finden und Information dazu anzuzeigen. Hier ist ein Beispiel: Found one Java-level deadlock:  =============================  "Thread-4":  waiting to lock monitor 0xb4868 (object 0xf203fdf8, a java.lang.Object) in JNI, which is held by "Thread-1"  "Thread-1":  waiting to lock monitor 0xb4910 (object 0xf203fe00, a java.lang.Object), which is held by "Thread-2" "Thread-2":  waiting to lock monitor 0xb4830 (object 0xf6112a60, a java.lang.String), which is held by "Thread-3"  "Thread-3":  waiting to lock monitor 0x119520 (JVMDI/JVMPI raw monitor), which is held by "Thread-4"  Nested-Monitor-Situationen werden dabei allerdings nicht gefunden, weil dafür – wie schon erwähnt – semantisches Wissen erforderlich ist, das einem Tool nicht zur Verfügung steht. Profiler Im Rahmen der Java Platform Debugger Architecture (JPDA) können Diagnose-Agenten in die JVM eingehängt werden (siehe / JPDA /). Diese Agenten bedienen sich des JVMPI (Java Virtual Machine Profiler Interface) oder des  JVMTI (Java Virtual Machine Tool Interface). JVMPI existiert seit JDK 1.2 und wird in JDK 1.5 durch JVMTI abgelöst. Beide Schnittstellen erlauben umfangreiches Profiling, z.B. zum Speicher- oder CPU-Verbrauch, aber auch zu den Thread-Zuständen.  Profiler-Agenten werden von verschiedenen JVM-Herstellern angeboten.  Der Standard-Profiler-Agent von Sun beispielsweise ist als HPROF bekannt (siehe / HPROF /). Man kann HPROF-Output über die Option –Xrunhprof anstoßen.  Um Information für die Threads zu bekommen würde etwa man folgende Option angeben: java –Xrunhprof:monitor=y com.ibm.test.stresser Die JVM schreibt dann Information über die Threadzustände in eine Ausgabedatei. Hier ein Auszug eines solchen Outputs: THREAD START (obj=7c5e60, id = 1, name="Signal dispatcher", group="system")  THREAD START (obj=7c6770, id = 2, name="Reference Handler", group="system")  THREAD START (obj=7ca700, id = 3, name="Finalizer", group="system")  THREAD START (obj=8427b0, id = 4, name="SymcJIT-LazyCompilation-PA", group="main")  THREAD START (obj=7c0e70, id = 5, name="main", group="main")  THREAD START (obj=87d910, id = 6, name="First", group="main")  THREAD START (obj=87d3f0, id = 7, name="Second", group="main")  THREAD START (obj=842710, id = 8, name="SymcJIT-LazyCompilation-0", group="main")  THREAD END (id = 6)  THREAD END (id = 5)  THREAD START (obj=87e820, id = 9, name="Thread-0", group="main")  THREAD END (id = 9) MONITOR DUMP BEGIN  THREAD 8, trace 1897, status: CW   THREAD 7, trace 1898, status: CW  THREAD 6, trace 1899, status: MW   THREAD 9, trace 1888, status: CW   THREAD 5, trace 1900, status: CW   THREAD 4, trace 1901, status: CW   THREAD 3, trace 1902, status: CW   THREAD 2, trace 1903, status: R   MONITOR ThreadTest(8ecb50)    owner: thread 7, entry count: 2    waiting to be notified: thread 8   MONITOR SymantecJITCompilationThread(8b1e00) unowned    waiting to be notified: thread 5   RAW MONITOR "_Hprof CPU sampling lock"(0x8b2f70)    owner: thread 6, entry count: 1   RAW MONITOR "SymcJIT Lazy Queue Lock"(0x8b1d34) unowned    waiting to be notified: thread 9 MONITOR DUMP END  Leider muss man hinzufügen, dass der HPROF-Monitor-Dump relativ unzuverlässig ist und nur gelegentlich funktioniert.  Es kann passieren, dass HPROF mit internen Fehlern abstürzt und gar keine brauchbare Information über die Threads produziert.  Das ist ein bekanntes Problem, von dem man nur hoffen kann, dass es in JDK 1.5 mit Umstellung auf die neue JVMTI-Schnittstelle behoben wird. Management Beans Schließlich wären noch die Java Management Beans (MXBeans) zu erwähnen. Sie sind neu in JDK 1.5 hinzugekommen (siehe / JSR163 / und / JSR174 /) und bieten eine Schnittstelle für den programmatischen Zugang zu Profiling- und Monitoring-Informationen der JVM.  Für die Deadlock-Analyse ist die ThreadMXBean von Interesse; es gibt daneben eine ganze Reihe anderer MXBeans im Package java.lang.management. ThreadMXBean. ist ein Interface. In der JVM existiert genau eine Instanz der ThreadMXBean.  Zugang zur MXBean holt man sich über eine Factory mit dem Aufruf ManagementFactory.getThreadMXBean().  Die ThreadMXBean liefert dann Informationen über die Threads und deren Zustände. Das funktioniert über Methoden wie long[] getAllThreadIds(), getThreadInfo (long id) und ThreadState getThreadState(long id).  Man bekommt Informationen über die Threads, wie Thread ID und Threadname, Threadzustand (New, Running, Blocked on entering or reentering a synchronization block, Waiting for notification, Timed waiting for notification, Sleeping, Terminated, Other), den Thread, der das Objekt blockiert, auf dessen Mutex der Thread wartet, usw. Man kann sogar eine Deadlock-Analyse über die Methode long[] findMonitorDeadlockedThreads() anstoßen.  Monitoring- und Debug-Methoden in ReentrantLock, ReentrantReadWriteLock und Semaphore Bei allen bisher genannten Hilfsmittel muss man leider anmerken, dass sie nur mit dem alten impliziten Mutex und den impliziten Conditions funktionieren.  Die im JDK 1.5 neuen expliziten Locks und Conditions sind nicht integriert, nicht einmal in die in JDK 1.5 neuen Management Beans.  Stattdessen habe die neuen Abstraktionen selbst ein Monitoring-Interface. Die Klasse ReentrantLock bietet beispielsweise Methoden, die Informationen darüber geben, ob der Mutex gesperrt ist, wie oft er angefordert wurde und von welchem Thread er gehalten wird.  Die Methoden sehen so aus: public boolean isLocked() public boolean isHeldByCurrentThread() public int getHoldCount() protected Thread getOwner() Daneben werden Informationen darüber geliefert, welche Threads darauf warten, den Mutex zu sperren. public boolean hasQueuedThreads() public int getQueueLength() public boolean hasQueuedThread(Thread thread) protected Collection<Thread> getQueuedThreads() Die Klassen ReentrantReadWriteLock und Semaphore haben ähnliche Methoden. All diese Monitoring- und Debug-Methoden ermöglichen den programmatischen Zugang zu den Information, die bei der Suche nach einem Deadlock helfen können.

Literaturverweise

If you are interested to hear more about this and related topics you might want to check out the following seminar:

Seminar   Concurrent Java - Java Multithread Programming 4 day seminar ( open enrollment and on-site)