私は、JVMプロセスで定期的なスレッドダンプを取るシステムを構築しようとしています。私はスレッドダンプを取っている間にJVMに最小のオーバーヘッドを引き起こすつもりです。スレッドダンプを取る方法は複数あり、最終的にはカスタムJVMTIエージェントを構築するか、ThreadMXBeanを使用するかの2つの選択肢があります。誰かがどのアプローチでJVMのオーバーヘッドが最小限になるのか分析したのでしょうか？それとも同じオーバーヘッドを引き起こすのでしょうか？JVM上で定期的なスレッドダンプを取る - ThreadMXBeanとJVMTIエージェント
サンプリングの頻度に少し依存しますが、ほとんどの場合、影響があり、結果に偏りが生じます。しかし、JVMTIの場合は正直なプロファイラを見てください。https://github.com/RichardWarburton/honest-profiler
ありがとうございます。安全点とAsyncGetCallTraceについて知ることは良いことです。これは私の研究にとって非常に便利です。 – Aniket
'AsyncGetCallTrace'はプロファイリングに適しています。ただし、スレッドダンプは作成されません。私。 'AsyncGetCallTrace'は**アクティブ**スレッドの素敵なトレースを得ることができますが、すべてのスレッドの画像は表示されません。 – apangin
合意。私のユースケースは、ほとんどすべてのスレッドが特定の瞬間に何をしているかのビューを取得するのではなく、プロファイリングの必要性です。 – Aniket
'ThreadMXBean'はスレッドダンプを取得する最悪の方法です。スタックトレースのJavaレベルの表現を構築します。そのため、スタックが遅くなり、ヒープに多くのゴミが生成されます。 JVMTIは良い方法です。ただし、スタックトレースを作成するようにJVMに依頼することもできます（リンクされた回答を参照）。 – apangin
質問をリンクしていただきありがとうございます。 JVMに求めるのは、私の（プロファイリング）ユースケースでは不要な、安全なポイントのwaitibgを意味します。 perfツールやDTraceの使用を実際に見てきました。 – Aniket
スタックトレースの主な目的がCPUプロファイリングの場合は、質問の言い換えが必要な場合があります。現在の形では、質問は実際にすでに答えられています。 – apangin