Wie ckhan erwähnte, jstack ist großartig, weil es den vollständigen Stack-Trace aller aktiven Threads in der JVM liefert. Dasselbe kann auf stderr der JVM mit SIGQUIT abgerufen werden.
Ein weiteres nützliches Tool ist jmap die einen Heap-Dump vom JVM-Prozess mithilfe der PID des Prozesses abrufen kann:
jmap -dump:file=/tmp/heap.hprof $PID
Dieser Heap-Dump kann in Tools wie visualvm geladen werden (das jetzt Teil der standardmäßigen Oracle-Java-SDK-Installation mit dem Namen jvisualvm ist). Darüber hinaus kann VisualVM eine Verbindung zur laufenden JVM herstellen und Informationen über die JVM anzeigen, einschließlich Diagrammen zur internen CPU-Nutzung, Thread-Anzahl und Heap-Nutzung – ideal zum Aufspüren von Lecks.
Ein weiteres Tool, jstat , kann Garbage-Collection-Statistiken für die JVM über einen bestimmten Zeitraum sammeln, ähnlich wie vmstat, wenn es mit einem numerischen Argument ausgeführt wird (z. B. vmstat 3 ).
Schließlich ist es möglich, einen Java-Agenten zu verwenden, um die Instrumentierung zur Ladezeit auf alle Methoden aller Objekte zu übertragen. Die Bibliothek javassist kann dazu beitragen, dies sehr einfach zu machen. Es ist also möglich, Ihre eigene Ablaufverfolgung hinzuzufügen. Der schwierige Teil dabei wäre, einen Weg zu finden, Trace-Ausgaben nur dann zu erhalten, wenn Sie es wollten und nicht immer, was die JVM wahrscheinlich zu einem Crawl verlangsamen würde. Es gibt ein Programm namens dtrace das funktioniert so ähnlich. Ich habe es versucht, war aber nicht sehr erfolgreich. Beachten Sie, dass Agenten nicht alle Klassen instrumentieren können, da diejenigen, die zum Bootstrap der JVM benötigt werden, geladen werden, bevor der Agent instrumentieren kann, und es dann zu spät ist, Instrumentierung zu diesen Klassen hinzuzufügen.
Mein Vorschlag - Beginnen Sie mit VisualVM und sehen Sie, ob Ihnen das sagt, was Sie wissen müssen, da es die aktuellen Threads und wichtige Statistiken für die JVM anzeigen kann.
Ebenso können Sie beim Debuggen von Programmen, die auf einem Linux-System schief gelaufen sind, ähnliche Tools verwenden, um laufende JVMs auf Ihrem System zu debuggen.
Tool Nr. 1 - jvmtop
Ähnlich wie top , können Sie jvmtop verwenden, um zu sehen, welche Klassen innerhalb der laufenden JVMs auf Ihrem System ausgeführt werden. Nach der Installation rufen Sie es wie folgt auf:
$ jvmtop.sh
Seine Ausgabe ist ähnlich gestaltet, um wie das Werkzeug top auszusehen :
JvmTop 0.8.0 alpha amd64 8 cpus, Linux 2.6.32-27, load avg 0.12
http://code.google.com/p/jvmtop
PID MAIN-CLASS HPCUR HPMAX NHCUR NHMAX CPU GC VM USERNAME #T DL
3370 rapperSimpleApp 165m 455m 109m 176m 0.12% 0.00% S6U37 web 21
11272 ver.resin.Resin [ERROR: Could not attach to VM]
27338 WatchdogManager 11m 28m 23m 130m 0.00% 0.00% S6U37 web 31
19187 m.jvmtop.JvmTop 20m 3544m 13m 130m 0.93% 0.47% S6U37 web 20
16733 artup.Bootstrap 159m 455m 166m 304m 0.12% 0.00% S6U37 web 46
Tool Nr. 2 - jvmmonitor
Eine andere Alternative ist die Verwendung von jvmmonitor. JVM Monitor ist ein in Eclipse integrierter Java-Profiler zur Überwachung der CPU-, Thread- und Speichernutzung von Java-Anwendungen. Sie können es entweder verwenden, um automatisch ausgeführte JVMs auf dem lokalen Host zu finden, oder es kann eine Verbindung zu entfernten JVMs herstellen, indem Sie [email protected]
verwenden
Tool Nr. 3 – visualvm
visualvm ist wahrscheinlich "das Tool", das man beim Debuggen von Problemen mit der JVM erreichen sollte. Sein Feature-Set ist ziemlich umfangreich und Sie können einen sehr detaillierten Blick auf die Innereien werfen.
Erstellen Sie ein Profil der Anwendungsleistung oder analysieren Sie die Speicherzuweisung:
Thread-Dumps erstellen und anzeigen:
Referenzen
- visualvm-Tutorial
Betrachten Sie jstack .Nicht ganz passend für strace , eher ein pstack -analog, gibt Ihnen aber zumindest ein Bild einer Momentaufnahme. Könnte sie aneinanderreihen, um eine grobe Spur zu erhalten, wenn es sein müsste.
Siehe auch die Vorschläge in diesem SO-Artikel:https://stackoverflow.com/questions/1025681/call-trace-in-java