問題タブ [thread-dump]

単一の物理ホストでアプリケーションの複数のインスタンス (Tomcat サーバーごとに 1 つ) を実行しています。アプリケーションは適切なロギングを行います。最近、一部のアプリケーションが遅くなったりハングしたりし、再起動する必要があることが確認されました。スレッド ダンプでは、ログ ステートメントですべてのスレッドがブロックされ、printlnオブジェクトのロックを待機していることがわかります。および他のオブジェクトがすでにロックを取得していますprintln。しかし、他のスレッドがprintlnオブジェクトのロックを解放しなかった理由がわかりませんでしたか? いくつかのスレッド ダンプ スナップショットを貼り付けます。

ブロックされたスレッド ダンプ:

printlnのログを取ったスレッドのスレッドダンプ。

jstack を使用して、CPU 使用率が最も高い PID のスレッド ダンプを取得しました。nid 0x4974 のスレッドを指していました。

"VM Thread" prio=10 tid=0x00007ffc60068800 nid=0x4974 runnable "VM Periodic Task Thread" prio=10 tid=0x00007ffc60098000 nid=0x497b 条件付き待機 JNI グローバル参照: 1182

Web で見たサンプル スレッド ダンプとは異なり、スレッドの状態と実行されているコードがないため、分析の進行に問題があります。.txtそして、スレッドダンプファイルを分析できるオンラインのフリーウェアはありますか?

答えてくれた人ありがとう。わかりましたので、samurai、tda、および ibm スレッド ダンプ ツールの使用方法を学ぶことができました。問題は、作成されるスレッドの数、モニターを待機しているスレッド、ロックおよびブロックにあるようです。しかし、追加の入力があるかどうか疑問に思っていました。これは私がTDAから得たものです：

CPU使用率が100%のとき

リセットしたら

すべてのスレッドの 40% がモニター上でスリープ状態になっています。

これは、オーバーロードされているか利用できない外部リソース (データベースなど) を待っているか、何かを実行するために待機していること (アイドルスレッド) を示している可能性があります。すべてのアイドル状態のスレッドを除外するフィルターを使用して、スリープ状態のスレッドを確認する必要があります。

お客様は60名ほどです。

CPU 使用率が 100% のときに、リセット後にスレッドダンプをアップロードしました。I also included the tools that i used (samurai,tda,and ibm thread and monitor dump analyzer) http://www.mediafire.com/?901mduvodm97d8v,x72cdixp8fltabu,fhfw4e50c7fzu4t,1oq2npaxmtxz0dq,i0u997fhvxfagd3,cdewe4de6x3rhe4,w2ndwqw2ekwixkd,qsbst5ow6f59p75,9fx8w8qpfdhjmyx, levpqppb3ouh71q

jmap を使用してヒープ ダンプを取得しました。Eclipse MATにロードしました。java.lang.Thread がトップ コンシューマです。直接ドミネーターをクリックすると、17K オブジェクト (org.jboss.security.SecurityAssociation$SubjectContext) を含む ArrayList が表示されます。

別の時間 (2 時間間隔) にヒープ ダンプを取得しました。

java.lang.Thread @ 0xd09f05d0 プール 7 スレッド 1 スレッド 112 | 12,198,024 | 7.64%

java.lang.Thread @ 0xd09e64c8 プール 7 スレッド 1 スレッド 112 | 19,037,464 | 8.58%

浅いヒープ: 112 保持ヒープ: 19,037,464 パーセンテージ 8.58

ヒープサイズが増加しています。

スレッド オブジェクト (0xd09f05d0 、0xd09e64c8 ) は異なり、スレッド名は同じです (pool-7-thread-1)。まだ同じスレッドを参照していて、ヒープが大きくなっていますか? または、1 つのスレッド (0xd09f05d0) が操作を完了し、別のオブジェクト (0xd09e64c8) を持つ同じスレッドが別の操作に使用され、別のオブジェクトを保持していますか?

これはJava thread dump: BLOCKED thread without "waiting to lock ..." に似ています。

基本的に、ブロックされたスレッドが表示されますが、待機中のロックがあります。

- waiting to lock <0x0000000742444ad0>...の代わりに が表示されることを期待しています- locked...。もう 1 つの質問は、ガベージ コレクションが原因であることを示唆していますが、その場合、すべてのスレッドがブロックされるわけではありませんか? RUNNABLE である他のスレッドがあります。また、それが事実であったことをどのように証明できますか？なぜこれが観察された動作になるのでしょうか? それがガベージコレクターであると盲目的に考えて、数日後にそれが別のものであることが判明するのは嫌です。

==補助情報==

当面の問題とは関係ないと思いますが、これは上記のダンプの元となったコードのセクションです。

明らかに、その行で取得する必要があるロックがあります。ただし、このモニターでスレッドが実際にブロックされている場合、スレッド ダンプの出力は次のようになります (これは同じダンプからのものです)。

私が興味を持っているダンプのセクションは異なって見えます (「ロック待ち」ではなく「ロック済み」)。多くのデッドロックをデバッグし、多くのスレッド ダンプを調べました。私がいつも目にするのは、「ロック待ち」です。「ロックされている」が「モニターのエントリを待機している」スレッドを見たことがなく、それが何を意味するのか知りたいです。

最近、Drools をシステムに導入しましたが、しばらくしてからサーバーが誤動作し始めました (クラッシュまたはレイテンシーの増加)。スレッド ダンプを分析し、そのスニペットを以下に示します。このプールのほとんどのスレッドは BLOCKED STATE です。

同じことの詳細な原​​因が何であるかを知りたいだけです。このような問題を防ぐために、他にどのような構成を行う必要がありますか。

====JAVA CONFIGで更新

StatefulKnowledgeSessionpublic StatefulKnowledgeSession getStatefullSession()メソッドを使用しています。このクラスの Spring Bean を作成し、他のクラスに注入して drools を使用します。

私たちのアプリケーションは遅れています。

jstackutilを使用してスレッド ダンプを取得しています。

データの準備と並べ替えを行います。そして、これは私が持っているものです:

198 のスレッドがブロックされています。

からわかるようにwaiting to lock <0x0000000582e56bc8>、それらはすべて ID のスレッドを待っています0x0000000582e56bc8。奇妙なことに0x0000000582e56bc8、スレッド ダンプ出力でこれを見つけることができず、彼らが何を待っているかを見つけることができません。

それとも真実ではありませんか？これは何0x0000000582e56bc8ですか？

ここにダンプの小さな平和があります：

他の 198 個のスレッド ダンプはすべて同じです

更新 1. @Holder コメントの後

更新 2 @Holder に感謝

私が理解しているようwaiting to lock <0x0000000582e56bc8>に、 は、スレッドが0x0000000582e56bc8ポインタである を待っていることを意味します。次に、 を見つける必要があります- locked <0x0000000582e56bc8>。そして、オブジェクトをロックしたスレッドが見つかります。それからスタックトレースを見て、最後に犯人を見つけました。

にも問題がある場合は、この質問com.sun.xml.bind.v2.runtime.reflect.opt.AccessorInjectorを見てください。

スレッド ダンプで、次の行を見つけました。

これを実装または開始するクラスを見つけるにはどうすればよいですThreadかRunnable?