問題タブ [thread-dump]

ctrl+break と Java プログラムによって取得されたスレッド ダンプの違いは何ですか?
以下のスニペットを使用してスレッド ダンプを取得しています

Map st = Thread.getAllStackTraces();

スレッド ダンプを取得するためのアプローチの違いを分析しています。以下は、私が研究しているそれらのカップルです

1. 宣言された Bean 操作をクリックすると、Runtime.exec() を介して jstack をトリガーする jmx Bean を定義します。

2. 「ManagementFactory.getThreadMXBean().dumpAllThreads(true, true)」を定義済みの間隔で繰り返し実行するデーモン スレッド。

2 つのスレッド ダンプ出力を比較すると、アプローチ 2 には以下の欠点があります。

1. アプローチ 2 でログに記録されたスレッド ダンプは、TDA などのオープン ソースのスレッド ダンプ アナライザーでは解析できません。
2. 出力には、CPU 使用率が高い問題の分析に役立つ可能性があるネイティブ スレッド ID が含まれていません (そうですか?)
3. もう？

提案/入力をいただければ幸いです

1. プロダクションコードで Runtime.exec() を介して jstack を実行することの欠点はありますか? さまざまなオペレーティング システム (Windows、Linux) での互換性の問題はありますか?

2. スレッド ダンプを取得する他の方法はありますか?

ありがとうございました。

編集 -

1 と 2 を組み合わせたアプローチが有効なようです。専用のスレッドをバックグラウンドで実行し、スレッド ダンプ アナライザーが理解できる形式でログ ファイルにスレッド ダンプを出力することができます。jstack 出力によってのみログに記録される追加情報 (おそらくネイティブ スレッド ID など) が必要な場合は、必要に応じて手動で行います。

ほとんどのスレッドが(state = IN_NATIVE)状態になっているアプリケーションで、ホストのスレッド ダンプを取得しました。

これらのインスタンスでブロックされたのは、いくつかのスレッドのみです。

と

と

いくつかのリクエストを行いHttpConnections、構成可能な時間の経過後にリクエストがタイムアウトしました。ホストを再起動すると、すべてが正常に戻りました。

したがって、スレッドはある時点でブロックされているはずだと思います。

NATIVE コードで実行されているスレッドは、ここを指していました。

これが犯人だと思います。これらの呼び出しを行うライブラリを内部的に使用ImageIOしています。Jsoup

スレッド ダンプの読み取りについてはよくわかりません。しかし、どんな助けでも大歓迎です。

ネイティブに実行されているすべてのスレッドが問題を引き起こしている可能性はありますか? どのように進めればよいですか？

ありがとう、

アプリケーション スレッド ダンプでは、次のような 5 つのスレッドを含むスレッドプールを確認できます。

しかし、私はこのようなものを直接使用したり、依存関係でこのようなものを見たりしません。

これは何 (hidden.edu.emory.mathcs.backport) で、なぜ使用したのですか (jdk 7 で実行されているアプリケーション)? アプリケーションのどの部分が開始されているかを検出できますか?

重い負荷の下でパフォーマンスが低下するリクエストがいくつかあるWebサーバーがあります。定期的に試してみたテクニックを使ってみましたが、いろいろな問題があります。

試みられた技術

1. Yourkitでのサンプリング/トレースプロファイリング
   • パフォーマンスが低下した特定のリクエストはごくわずかだったため、負荷がかかった状態でプロファイラーを使用できませんでした。
   • 単一のリクエストをテストするだけでは、パフォーマンスの問題は再現されません
2. スレッドダンプ
   • 一定の間隔でスレッドダンプを試みましたが、間隔が大きいと実際に何が遅いのかわかりにくく、間隔が短いとサーバーのパフォーマンス特性に大きな影響を与えました。

サーバーに負荷がかかっているときに単一のリクエストのパフォーマンスをプロファイリングするにはどうすればよいですか？

次のスレッドダンプがあり（以下を参照）、デッドロックがあるかどうかわかりません。

誰かアドバイスしてもらえますか？

プロセスでjstackを実行しましたが、デッドロックは検出されませんでした。ただし、Webアプリケーションを実行するとTomcatが無期限にハングし、次のコードが9回実行されます。

デッドロックでない場合、他に何ができるでしょうか。

私は事後分析とサーバーのスローダウン分析に Java スレッド ダンプをよく使用します。問題は、スレッド ダンプが長くなることが多く、スレッド間の同時実行関係を理解するのが面倒な場合があることです。

Java Thread Dump を解析し、人間が読める要約を表示できる (できればオンラインの) ツールはありますか?

負荷テストの不具合を解明するために必死に何かを試しているときに、Java 用のスレッド ダンプ分析ツールであるTDAに出会いました。どういうわけか、私はその出力に従っているとは感じません。たとえば、8 つのスレッドが BLOCKED であるモニター インスタンスがある場合、RUNNABLE 状態のスレッドが 1 つあるはずではありませんか? 他の 8 つのスレッドを BLOCKED 状態にするために、一部のスレッドがそのモニターのロックを取得する必要がありましたね。

次に、TDA 用語についてですが、「モニターでスリープしているスレッド (675 スレッドがスリープしている)」というカテゴリと、「スレッド ロック モニター (806 スレッド ロック)」というカテゴリがあります。これらのカテゴリには両方とも、WAITING、BLOCKED、または TIMED_WAITING のスレッドが含まれています。私が言える唯一の違いは、後者のカテゴリには RUNNABLE 状態のスレッドも含まれているということです。それらの間に他の違いはありますか？私が得られないのは、「モニターで寝ている」という構文です。

ありがとう！

JNI を使用して実装されたネイティブ共有ライブラリの jvisualvm によって生成されたスレッド ダンプが提供されました。Dot.Net の Parallel.For を介して複数のスレッドから呼び出しているアプリで実行されています。ライブラリの Java 部分にはスレッド プールがありますが、そのサイズには制限があり、ライブラリのネイティブ部分自体はスレッドを作成しません。

発生しているように見えるのは、ますます多くのスレッドが作成され、最終的にアプリがメモリ不足エラーでクラッシュすることです。奇妙なことに、基本的にアプリが行っていることは、Parallel.For 内のループ内でライブラリを呼び出すことだけであり、それによって作成されたスレッドは「リーク」してはなりません (そうですか?)。

スレッド ダンプには、次の形式のエントリが多数含まれています。

それは正確にはどういう意味ですか？