64

Java アプリケーションがハングしている場合、これにつながるユース ケースもわからず、調査したい場合、スレッド ダンプが役立つことは理解しています。

しかし、スレッド ダンプから有用なデータを簡単に取得して、問題の場所を特定するにはどうすればよいでしょうか。私が使用しているサーバー アプリケーションは、非常に長いスレッド ダンプを生成します。これは、EJB アーキテクチャであり、スレッド ダンプには、確認する必要があるかどうかわからないコンテナー スレッド (つまり、アプリケーション コードを実行していないスレッド) が多数含まれているためです。 、しかし JBoss のコード)。

昨日、Thread Dump Analyzerツールを試しました。このツールは、テキスト エディターで生のスレッド ダンプを見るよりもはるかに優れています。興味のないスレッドをフィルターで除外し、スレッド リストを表示し、スレッドをクリックして詳細を表示し、スレッド ダンプを比較して見つけることができるからです。長時間実行スレッドなど

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

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

4

3 に答える 3

31

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

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

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

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

于 2011-07-24T15:36:51.733 に答える
30

1 セットのスレッド ダンプだけでは、根本原因を突き止めるのにあまり役に立ちません。

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

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

これらをSamuraiで実行すると(私自身は TDA を使用していません)、これらが赤色で強調表示されるので、すばやくクリックして問題を示す行に到達できます。

この例をここで参照してください。そのリンクの Samurai の出力画像を見てください。緑のセルは問題ありません。赤と灰色のセルを確認する必要があります。

以下の私自身の Web アプリからの Samurai の例は、5 秒から 10 秒にわたってスレッド '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)

アップデート

私は最近、この回答で言及されているJava Thread Dump Analyzerを使用しましたが、Samuraiとは対照的にTomcatに非常に役立ちました

于 2010-07-01T11:25:09.077 に答える
7

現在「実行可能」状態にあるスレッドのみを見るべきなのか、それとも「条件待ち」と「Object.wait」も重要なのかはわかりません。

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

もちろん、アプリケーション コンテナーには、正当に待機しているスレッドが多数あります。興味深いケースを除外するには、スタック トレースを調べます。それがフレームワーク クラス (特に "Worker" または "Queue" と呼ばれるもの) であれば、おそらく問題ありません。それがアプリケーション コードである場合は、より詳しく調べる必要があります。

于 2010-07-01T09:33:50.997 に答える