Thread-Debugging, wie?

[Wolfram]

Multithreading ist nicht für Menschen gemacht, glaub ich ... das ist ja die GOTO-Problematik hoch 10. Echt eklig.

Ich wüsste gerne, was für Möglichkeiten es gibt, Java-Threads zu debuggen? Ich stelle mir z.B. ein Tool vor, das Start und Beenden, wait() und notify() hübsch grafisch darstellt, woran man dann sehen könnte, dass ein Thread gar nicht gestartet wurde, oder ein Thread auf ein notify() wartet, das nie kommt, und dergleichen mehr.

Hintergrund: Momentan arbeite ich mit System.out.println und logge mit, wann was startet/terminiert, aber das hat mein aktuelles Problem nicht abgefangen, dass ich versehentlich run() statt start() aufgerufen habe.

Gibt's da was interessantes? Oder wie debuggt Ihr Eure Threads?

 

[byte]

Wenn möglich arbeite ich gar nicht mit wait() / notify() ... Ansonsten würde ich Dir raten, falls Du Java 5 verwendest, Dir mal das Concurrency Framework anzugucken. Das bietet eine recht gute Abstraktion gegenüber Threads und vereinfacht die Handhabung ungemein. Für Concurrency in Swing ist der SwingWorker noch interessant. Ansonsten empfehle ich einen Debugger zu benutzen, wie ihn z.B. Eclipse bietet. Statt System.out würde ich dann noch einen Logger wie log4j einsetzen. Richtig konfiguriert schreibt er Dir direkt mit in die Ausgabe, aus welchem Thread die Message kommt.

 

[Marco13]

Naja - der Debugger, der z.B. bei Eclipse dabei ist, erlaubt es ja, z.B. auf "Pause" zu stellen, und nachzusehen, was die Threads so gerade machen....

 

[fehlerfinder]

log4j - wie der Kollege schon sagte. Gegen run() statt start() hilft nur Doku-Studium ;-)

Frameworks zur Abstraktion sind bestimmt schön und gut (auch wenn ich mich - ehrlich gesagt - damit noch nicht beschäftigt habe), aber man sollte auf alle Fälle die Grundlagen der Thread-Programmierung, -Behandlung, -Anwendung (was-auch-immer) VERSTANDEN haben - so richtig. Dazu empfehle ich die einschlägige Doku im Netz, sei's nun die "Java-Insel" aus dem Galileo-Verlag oder das Sun-Tutorial. Und dann schreibst du jede Menge KLEINE Klassen, die sich einen speziellen Teil der Thread-Bearbeitung vornehmen und darüber Protokoll führen - z.B. per log4j oder aber auch mit vernünftig parametrierten System.out-Statements (aber bevor du die vernünftig parametriert hast, hast du dich auch in log4j eingearbeitet ;-) )

Danach(!) passiert dir dann sowas wie run/start nicht mehr.

Für die Erkennung von Dead-Locks, die z.B. bei unvoreingenommener Verwendung von synchronized-Blöcken auftreten können, gibt es dann Samurai, ein grafisches Debugging-Tool für die Auswertung von Thread-Dumps. Einen solchen Dump erstellst du unter Linux per "kill -3 <pid>", wobei <pid> natürlich die process-id deines Java-Programms ist. Wie das unter Windows geht, kann ich leider nicht sagen.

 

[Wolfram]

Danke für die Antworten so weit!

Kurz zur Klärung, weil Ihr alle drauf eingegangen seid, dass ich System.out.println geschrieben habe, bezog sich auf die Debugging-Methode - ich wollte nicht printf()-Debugging schreiben Der Applikation-Server lenkt stdout bereits auf log4j um, und erspart mir das somit. Auch arbeite ich nicht direkt mit den Monitor-Funktionen, da wird man ja komplett wahnsinnig. Ich bin heilfroh, dass es das Concurrent-Framework gibt. Von einem Debugger würde ich aber nicht mehr erwarten, als dass ich wait() und notify() angezeigt bekomme.

Was ich soweit gelernt habe,

* jstack zeigt einem auf der Konsole Stack-Traces aller Threads an, das kann aber für einen Application-Server recht unübersichtlich werden,

* der IDE-Debugger von NetBeans kann ebenfalls eine Liste aller threads und deren Zustand anzeigen, allerdings ist die Bedienung etwas schwierig,

* *ganz wichtig* man sollte in so einem Fall "seinen" Threads vernünftige Namen verpassen, Thread-342 ist etwas nichtssagend, also zu Anfang von run() einfach einmal this.setName("MeinThread-"+this.getName()) machen, damit man schnell überblicken kann, ob auch alle da sind etc.

Grüße,
Wolfram

 

[Janus]

artikel zu dem thema: http://www.javaspecialists.eu/archive/Issue147.html