Fügen Sie einen Dump ein oder laden Sie eine Datei. Die Analyse verknüpft Angaben dieser Momentaufnahme und überwacht keine laufende JVM.
Läuft lokal in deinem BrowserFügen Sie die Ausgabe von jstack oder jcmd Thread.print ein oder öffnen Sie eine .txt- oder .log-Datei, und drücken Sie Lokal analysieren. Der Dump wird in diesem Browser gelesen: die Übersicht zählt die Threads nach java.lang.Thread.State, die Karte darunter reiht die Stackframes nach Häufigkeit, und die Befunde nennen die Threads, die auf eine Sperre warten, die ein anderer Thread hält.
Ein Beispiel mit 13 Threads und 4,3 KB ergab RUNNABLE 4, WAITING 3, BLOCKED 2, TIMED_WAITING 2 und UNKNOWN 2, häufigster Frame war java.base/java.lang.Thread.sleep(Native Method) (3 Threads), und zwei HTTP-Worker warteten auf denselben Monitor, den cache-writer hielt. Nichts wird hochgeladen, und es bleibt keine Kopie des Dumps zurück.
Es wird nur Text ausgewertet, und nur in den Formen, die ein JVM-Dump schreibt: Thread-Kopfzeilen (ein Name in Anführungszeichen, gefolgt von prio=, tid= oder nid=), java.lang.Thread.State-Zeilen, at-Frames und die Zeilen waiting to lock / locked / parking to wait for, die jstack -l ergänzt. VM-Threads werden ohne Zustandszeile ausgegeben und landen deshalb in der Zeile UNKNOWN — zwei der dreizehn im obigen Beispiel.
Der Deadlock-Bericht, den jstack nach der Thread-Liste anhängt, wird als Bericht gelesen und nicht als weitere Threads: ein Dump mit drei Threads und einem Deadlock bleibt bei drei Threads, und der Bericht ergibt einen Befund plus eine Zeile je wartendem Paar.
Jeder Frame jedes Threads zählt, nicht nur die drei innersten, denn ein geteilter Frame tiefer im Stack ist genau das Muster eines wiederkehrenden Aufrufpfads. In einem Beispiel mit 24 Threads, deren fünfter Frame java.base/java.lang.reflect.Method.invoke(Method.java:568) ist, erscheint dieser Frame 18-mal im Dump und in der Tabelle.
Eine Sperrenkorrelation braucht beide Hälften im selben Dump: die Zeile waiting to lock <id> des einen Threads und die Zeile locked <id> eines anderen. Sperren, deren Halter nicht in der Datei steht — abgeschnittener Dump oder jstack ohne -l —, werden als Wartevorgang gezählt, aber es wird nichts über den Halter behauptet.
Die Größe ist praktisch kein Hindernis: ein Dump mit 240 Threads und 92 KB ergab 240 Threads, davon 6 blockiert an einem Monitor, und drei Frames mit je 240 Treffern, weil die Arbeit auf diesem Rechner stattfindet.
Ein HotSpot-Absturzprotokoll (hs_err_pid*.log) listet Java-Threads auf, enthält aber keine java.lang.Thread.State-Zeile; die Seite sagt das, statt leere Tabellen zu zeichnen. Jeder andere Text ohne eine einzige Thread-Kopfzeile bekommt dieselbe Antwort, und ein leeres Feld erhält einen Hinweis statt eines Ergebnisses.
Es wird immer ein Dump gelesen. Der Analysator verbindet sich nicht mit einer JVM, kann keinen laufenden Prozess beproben und beobachtet keine Dateiänderungen; für eine Live-Ansicht sind Flight Recorder oder ein Profiler das richtige Werkzeug.
Zustandsnamen, Frame-Signaturen und Sperren-IDs werden genau so ausgegeben, wie der Dump sie schreibt, auf Englisch, weil sie Daten sind; die Beschriftungen ringsum folgen der Seitensprache.