1

jboss 5.1 を実行していて、この GC データを取得しています

34.098: [GC 197635K->91639K(236480K), 0.0356348 secs]
37.139: [GC 217911K->100951K(239936K), 0.0541968 secs]
37.194: [Full GC 100951K->97239K(304704K), 0.3325776 secs]
38.602: [GC 214271K->97547K(285568K), 0.0488937 secs]
41.395: [GC 220811K->111699K(304512K), 0.0334592 secs]
42.734: [GC 235155K->115815K(304384K), 0.0208743 secs]
43.722: [GC 239271K->115801K(303872K), 0.0166861 secs]
44.373: [GC 241049K->118266K(304128K), 0.0106151 secs

フル GC がいつ発生するかを誰かが説明できますか? フル GC のときにヒープ サイズの前後に小さな差があるのはなぜですか。フルGCの前の行は「通常の」GCであり、この大きな違いがあります（そして収集時間は短いですか？）、この2行のタイムスタンプが非常に近いことに気付きました

4

1 に答える 1

0

あなたが見ているのは、コレクションが若い/エデン空間と古い空間の両方で起こっていることです。これらの 2 つのスペースでは、異なる種類のコレクターが使用されます。これは、これらのエリア内のオブジェクトの特性が異なるためです。これらのフル GC は通常、遅く、VM を停止させるため、最大の問題です。幸いなことに、まだ大きな問題は発生していませんが、問題はなぜ発生したのかということです。

残念ながら、言うことは不可能です。詳細を知りたい場合は、スイッチをアクティブにする必要があります-XX:+PrintGCDetails

ただし、推測できます。あなたが正しく指摘しているように、ヒープはいっぱいではなく (300MB のうち 100MB)、あまり収集されません (30MB)。したがって、この GC は への呼び出しが原因であると推測していますSystem.GC()。-XX:+DisableExplicitGCを使用してそれらが起こらないようにするか、実際にこれを行ったコードを見つけて削除する必要があります。

于 2012-11-27T20:17:29.780 に答える