22

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

  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 など) が必要な場合は、必要に応じて手動で行います。

4

4 に答える 4

34

使用できます

jstack {pid} > stack-trace.log

プロセスが実行されているボックスでユーザーとして実行されています。

これを複数回実行すると、a を使用して、diffアクティブなスレッドをより簡単に確認できます。

スタック トレースを分析するために、専用スレッドで定期的にサンプリングされた以下を使用します。

 Map<Thread, StackTraceElement[]> allStackTraces = Thread.getAllStackTraces();

この情報を使用して、スレッドの ID、実行状態を取得し、スタック トレースを比較できます。

于 2013-01-02T09:45:53.017 に答える
8

Java 8 を例にとると、jcmd が推奨されるアプローチです。

jcmd <PID> Thread.print

以下は、 Oracle ドキュメントのスニペットです。

JDK 8 のリリースでは、JVM および Java アプリケーションの問題を診断するための Java Mission Control、Java Flight Recorder、および jcmd ユーティリティが導入されました。診断を強化し、パフォーマンスのオーバーヘッドを削減するために、以前の jstack ユーティリティの代わりに最新のユーティリティ jcmd を使用することをお勧めします。

ただし、これをアプリケーションと一緒に出荷すると、ライセンスに影響する可能性がありますが、これはよくわかりません。

于 2016-12-14T16:35:02.060 に答える
6

*nix の場合は試してみkill -3 <PID>ますが、プロセス ID を知る必要があり、コンソールにアクセスできない可能性がありますか?

于 2013-01-02T08:35:35.383 に答える
1

そのような環境がある場合は、ステージング環境ですべてのヒープ分析を行い、必要なアプリケーションサーバーのチューニングがあればそれを本番環境に反映することをお勧めします。アプリケーションのメモリ使用率を分析するためにダンプが必要な場合は、より適切な分析のためにプロファイリングを検討する必要があります。

通常、ヒープ ダンプは、OutOfMemoryExceptionsメモリ リークや不適切なメモリ管理が原因で生成されます。

Application Server のドキュメントを確認してください。最近のほとんどのサーバーには、前述の通常の原因とは別に、実行時にダンプを生成する手段がありますが、結果のダンプはベンダー固有のものである可能性があります。

于 2013-01-02T08:42:32.837 に答える