java - JVisualVM では、構成の変更を気にすることなく、スレッド数が大幅に減少します

Question

ここ数日間 JBOSS アプリケーションを監視しており、スレッド数が 4000 から 6000 の範囲にあることを確認しました。 . ライブ ピーク スレッド数は約 6200 でした。現在、グラフのスレッド数は 600 ～ 800 の範囲です。

count の急激な減少には特別な理由がありますか? そのような詳細について詳細に説明している特定のガイドはありますか? このようなスレッド数の急激な増加の根本的な原因は何でしょうか? この場合、GC が登場しますか?

ありがとう。

Answer 1

count の急激な減少には特別な理由がありますか?

ほとんどの場合、キャッシュされたスレッド プールを使用しています。これらのタイムアウトは、ビジーではなく、一度に多くの (つまり、数十のスレッドを意味する) が死んでいるのを見ることができます。CPUよりも多くのスレッドを持つことは、一般的に私見では良い考えではなく、600-800でさえ正気ではありません。私見では。

そのような詳細について詳細に説明している特定のガイドはありますか?

スレッドの数が非常に多いシステムでは、通常、使用されているスレッドの数に誰も注意を払っていなかったり、スレッドが何をしているのか、本当に必要かどうかを心配したりしていないため、これが当てはまります。なぜそんなに多くのスレッドが必要なのかを説明できる人はいないと思います。

このようなスレッド数の急激な増加の根本的な原因は何でしょうか?

ここで、スタック ダンプとスレッド名を調べて、それらが何を行っているかを把握する必要がありますが、ほとんどの場合、キャッシュされたスレッド プールが 1 つか 2 つあり、スレッドの数が一時的に急増しています。

この場合、GC が登場しますか?

問題は発生しませんが、スレッドが増えると、すべてのスレッドが GC の実行に必要な安全なポイントに到達するまでの時間が遅くなります。何千ものスレッドを使用すると、実際にガベージをクリーニングするよりも、スレッドが安全なポイントに到達するまで GC が待機する時間が長くなることがわかります。