web-dev-qa-db-ja.com

スレッドダンプ分析ツール/メソッド

Javaアプリケーションがハングしている場合、これにつながるユースケースさえ知らないので調査したいのですが、スレッドダンプが役立つ可能性があることを理解しています。

しかし、問題がどこにあるのかを見つけるために、スレッドダンプから有用なデータを簡単に引き出すにはどうすればよいでしょうか？私が扱ってきたサーバーアプリケーションは非常に長いスレッドダンプを生成します。これはEJBアーキテクチャであり、スレッドダンプには多くのコンテナスレッドが含まれているためです。 、ただしJBossのコード）。

昨日、私は Thread Dump Analyzer ツールを試しました。このツールは、テキストエディターで生のスレッドダンプを確認するよりも間違いなく優れています。関心のないスレッドをフィルターで除外し、スレッドリストを表示し、スレッドをクリックして詳細を確認し、スレッドダンプを比較して見つけることができるからです長時間実行されるスレッドなど。以下のスクリーンショットを参照してください。

Thread Dump Analyzer

しかし、分析するデータがまだ多すぎるため、ほぼ300スレッドです。興味のないすべてのJBossスレッドを除外するために使用できる基準は知りません。現在「実行可能」状態にあるスレッドだけを見るべきか、「待機中」および「Object.wait内」も重要かどうかはわかりません。

あなたが通常従うアプローチと一般的に使用するツールは何ですか？

javadebuggingdeadlockthread-dump
63
Ivo Rossi

スレッドダンプの1つのセットだけでは、根本原因に到達するのにあまり役に立ちません。

トリックは、それぞれ5秒間隔で4〜5セットのスレッドダンプを取得することです。そのため、最後に、アプリサーバーで約20〜25秒のアクションがある単一のログファイルが作成されます。

チェックしたいのは、スタックスレッドまたは長時間実行されているトランザクションが発生した場合、すべてのスレッドダンプは、特定のスレッドIDがJavaスタックトレースの同じ行にあることを示します。トランザクション（EJBまたはデータベースなど）は複数のスレッドダンプにまたがっているため、さらに調査する必要があります。

これらを Samurai （私はTDAを使用したことはありません）で実行すると、これらが赤色で強調表示されるため、すばやくクリックして問題を示す行に移動できます。

this here の例を参照してください。そのリンクのSamurai出力画像を見てください。緑色のセルは正常です。赤と灰色のセルを見る必要があります。

以下の私自身のWebアプリのSamuraiの例は、5〜10秒のスパンでThread'19 'のスタックシーケンスを示しています

>     Thread dump 2/3 "[ACTIVE] ExecuteThread: '19' for queue:
> 'weblogic.kernel.Default
> (self-tuning)'" daemon prio=7
> tid=07b06000 nid=108 lwp_id=222813
> waiting for monitor entry
> [2aa40000..2aa40b30]     
> Java.lang.Thread.State: BLOCKED (on
> object monitor)      at
> com.bea.p13n.util.lease.JDBCLeaseManager.renewLease(JDBCLeaseManager.Java:393)
> - waiting to lock <735e9f88> (a com.bea.p13n.util.lease.JDBCLeaseManager)
> at
> com.bea.p13n.util.lease.Lease$LeaseTimer.timerExpired(Lease.Java:229)

...

> Thread dump 3/3 "[ACTIVE]
> ExecuteThread: '19' for queue:
> 'weblogic.kernel.Default
> (self-tuning)'"   daemon prio=7
> tid=07b06000 nid=108 lwp_id=222813
> waiting for monitor entry
> [2aa40000..2aa40b30]     
> Java.lang.Thread.State: BLOCKED (on
> object monitor)      at
> com.bea.p13n.util.lease.JDBCLeaseManager.renewLease(JDBCLeaseManager.Java:393)
> - waiting to lock <735e9f88> (a com.bea.p13n.util.lease.JDBCLeaseManager)
> at
> com.bea.p13n.util.lease.Lease$LeaseTimer.timerExpired(Lease.Java:229)

update

私は最近 Java Thread Dump Analyzer を使用しました この回答では であり、サムライとは対照的にTomcatに非常に役立ちました

29
JoseK

これは古い質問ですが、長いスレッドダンプを読みやすくするためのツールを作成しただけです。

Javaスレッドダンプ分析ツール

このツールは、同じスタックトレースを持つスレッドをグループ化し、特定の状態（たとえば、RUNNABLEまたはBLOCKED）のスレッドのみを表示できるようにします。

これにより、コード内の同じ場所で作業を待つことにほとんどの時間を費やしているため、すべて同じスタックトレースを持つ数十または数百のJBossスレッドの中から興味深いスレッドを見つけるのが少し速くなります。

29
mchr

現在「実行可能な」状態にあるスレッドだけを見るべきか、「待機中」および「Object.wait内」も重要かどうかはわかりません。

後者の2つは、実際にはtheデッドロックを診断するときに探すべきものです。 「実行可能」とは、スレッドが現在何かを実行している（またはCPUを取得するのを待っている）ことを意味します。 「ブロック」と「待機」がデッドロックの原因です。

もちろん、アプリケーションコンテナには、正当に待機するスレッドがたくさんあります。興味深いケースを除外するには、スタックトレースを見てください。フレームワーククラス（特に「ワーカー」または「キュー」と呼ばれるクラス）であれば、おそらく大丈夫です。アプリケーションコードの場合は、より詳しく調べる必要があります。

6
Michael Borgwardt