JVM スレッドダンプ解析
ダンプを貼り付けるかローカルファイルを読み込み、記録されたスレッドを確認します。このアナライザーはスナップショット内の情報を突き合わせるだけで、実行中の JVM を監視するものではありません。
ブラウザ内でローカルに実行ローカル処理 ·
jstack · jcmd Thread.print · .txt / .log
ダンプを貼り付けるかローカルファイルを読み込み、記録されたスレッドを確認します。このアナライザーはスナップショット内の情報を突き合わせるだけで、実行中の JVM を監視するものではありません。
ブラウザ内でローカルに実行jstack または jcmd Thread.print の出力を貼り付けるか、.txt / .log ファイルを開いて「ローカルで解析」を押します。ダンプはこのブラウザー内で読み取られ、概要は java.lang.Thread.State ごとのスレッド数を、下のカードは繰り返し現れるスタックフレームを、検出結果は他のスレッドが保持するロックを待っているスレッドをそれぞれ示します。
13 スレッド・4.3 KB のサンプルでは RUNNABLE 4、WAITING 3、BLOCKED 2、TIMED_WAITING 2、UNKNOWN 2 となり、最も多く現れたフレームは java.base/java.lang.Thread.sleep(Native Method)（3 スレッド）、2 つの HTTP ワーカーが cache-writer の保持するモニターを待っていました。アップロードは行われず、ダンプのコピーも残りません。
読み取るのはテキストのみで、しかも JVM のダンプが書く形だけです。スレッドのヘッダー（引用符で囲んだ名前の後に prio=、tid=、nid= が続く行）、java.lang.Thread.State 行、at フレーム、そして jstack -l が付ける waiting to lock / locked / parking to wait for 行です。VM スレッドは状態行を伴わずに出力されるため UNKNOWN の行に入ります（上記サンプルでは 13 件中 2 件）。
jstack がスレッド一覧の後に付けるデッドロックレポートは、レポートとして読み取られ、追加のスレッドとは見なしません。スレッド 3 件とデッドロック 1 件のダンプはスレッド 3 件のままで、レポートは検出結果 1 件と待機ペアごとの 1 行になります。
各スレッドのすべてのフレームを数えます（最も内側の 3 つだけではありません）。繰り返し現れる呼び出し経路は、スタックの深い位置にある共通フレームとして現れるためです。5 番目のフレームが java.base/java.lang.reflect.Method.invoke(Method.java:568) である 24 スレッドのサンプルでは、そのフレームはダンプ内でも表でも 18 回現れます。
ロックの対応関係には、同じダンプの中に両方の情報が必要です。あるスレッドの waiting to lock <id> 行と、別のスレッドの locked <id> 行です。保持者がファイル内にいないロック（途中で切れたダンプや -l なしの jstack）は待機として数えますが、誰が保持しているかは断定しません。
サイズは実質的な制限になりません。240 スレッド・92 KB のダンプは 240 スレッドとして返り、そのうち 6 件が同一モニターでブロックし、3 つのフレームがそれぞれ 240 回と数えられました。処理はすべてこの端末上で行われるためです。
HotSpot のクラッシュログ（hs_err_pid*.log）は Java スレッドを列挙しますが java.lang.Thread.State 行を含まないため、空の表を描く代わりにその旨を表示します。スレッドヘッダーが 1 つもないテキストも同じ扱いで、空の入力欄には結果ではなく警告が出ます。
読み取るのは 1 つのダンプのみです。このアナライザーは JVM に接続せず、実行中プロセスのサンプリングやファイルの監視も行いません。ライブの状態を見るには Flight Recorder やプロファイラーが適しています。
状態名・フレームのシグネチャ・ロック ID はデータそのものなので、ダンプが書いたとおりに英語で表示されます。その周囲のラベルはページの言語に従います。