8

VisualVM で Java プログラムを監視しているときに、ガベージ コレクターの動作に興味深いパターンがあることに気付きました。「通常の」ガベージ コレクションの実行を行った直後に、GC が 2 回目の CPU 集中型の実行を行うことがよくありますが、追加の効果はないようです (より積極的な実行後の使用済みヒープは、軽いランの後です）。

ガベージ コレクターの実行とそれに対応するヒープ使用量の変更を確認できる VisualVM の出力を示しました。

興味深いガベージ コレクターの動作

私の質問は、基本的にガベージコレクターがここで何をしているのか、そしてその理由は何ですか? 十分な空きメモリがあり、より軽い実行に対して目に見える利点がない場合に、これらの本当に CPU を集中的に使用する実行を試みる原因は何ですか? それとも、グラフを誤解していますか？

プログラムのパフォーマンスは実際には影響を受けません。ただ興味があるだけです。

4

1 に答える 1

2

グラフを見ることは、GC 実行の概要を把握するのに役立ちますが、特定の瞬間に GC が実行されている理由を調べたい場合は、GC ログを深く掘り下げる必要があります。

完全な GC ロギングを有効にし、jstat の収集も開始します。予期しない GC サイクルが発生した場合に注目し、ログで追跡します。そこに何が見えますか？見てみてください：

  • フルまたはマイナーGCですか？
  • エデン、パーマ、oldGen、サバイバースペースなどの職業は何ですか?
  • これらの間隔での割り当て率、ライブ データ セットのサイズ、昇格率とは?
  • 等

これらの質問に答えると、GC が実行されている理由の問題につながる可能性があります。

更新: GC の調整方法に関する技術的な詳細は、次のように見つけることができます: Is there a cookbook guide for GC problems?

于 2013-04-01T22:21:41.093 に答える