是什么原因导致 Java 7 中的 G1 垃圾回收器中止其并发标记阶段?

2022-09-04 04:09:21

我注意到在我的应用程序中偶尔使用G1垃圾回收器的完整GC,并试图找出它们发生的原因。

从一个区域扫描开始到下一个区域扫描的周期摘录如下。在 61807.406 处,将记录一个完整的 GC,后跟一个并发标记中止条目。我想知道的是,为什么GC觉得有必要做一个完整的,停止世界的垃圾收集,以及我如何避免它。

请注意,这个问题似乎以前在OpenJDK邮件列表中被问过,没有回答。

为了简洁起见,我已经修剪了年轻GC的细节,但如果需要,我可以在某个地方发布完整的块。

61805.878: [GC concurrent-root-region-scan-start]
61805.882: [GC concurrent-root-region-scan-end, 0.0033586]
61805.882: [GC concurrent-mark-start]
61806.133: [GC pause (young), 0.02836202 secs]
   [Eden: 498M(498M)->0B(478M) Survivors: 14M->34M Heap: 3025M(4096M)->2548M(4096M)]
 [Times: user=0.19 sys=0.00, real=0.03 secs] 
61806.426: [GC pause (young), 0.02766222 secs]
   [Eden: 478M(478M)->0B(480M) Survivors: 34M->32M Heap: 3050M(4096M)->2576M(4096M)]
 [Times: user=0.19 sys=0.00, real=0.03 secs] 
61806.717: [GC pause (young), 0.02214895 secs]
   [Eden: 480M(480M)->0B(502M) Survivors: 32M->10M Heap: 3056M(4096M)->2571M(4096M)]
 [Times: user=0.09 sys=0.00, real=0.02 secs] 
61807.000: [GC pause (young), 0.01899188 secs]
   [Eden: 502M(502M)->0B(502M) Survivors: 10M->10M Heap: 3074M(4096M)->2573M(4096M)]
 [Times: user=0.09 sys=0.00, real=0.02 secs] 
61807.201: [GC pause (young), 0.02619259 secs]
   [Eden: 162M(502M)->0B(500M) Survivors: 10M->12M Heap: 3036M(4096M)->2876M(4096M)]
 [Times: user=0.11 sys=0.00, real=0.03 secs] 
61807.283: [GC pause (young), 0.02068515 secs]
   [Eden: 102M(500M)->0B(500M) Survivors: 12M->12M Heap: 3058M(4096M)->2957M(4096M)]
 [Times: user=0.09 sys=0.00, real=0.02 secs] 
61807.350: [GC pause (young), 0.01606520 secs]
   [Eden: 52M(500M)->0B(498M) Survivors: 12M->14M Heap: 3020M(4096M)->2969M(4096M)]
 [Times: user=0.11 sys=0.00, real=0.02 secs] 
61807.389: [GC pause (young), 0.01573865 secs]
   [Eden: 42M(498M)->0B(500M) Survivors: 14M->12M Heap: 3021M(4096M)->2978M(4096M)]
 [Times: user=0.09 sys=0.00, real=0.02 secs] 
61807.406: [Full GC 2978M->2498M(4096M), 4.8896638 secs]
 [Times: user=6.37 sys=0.08, real=4.89 secs] 
61812.296: [GC concurrent-mark-abort]
61812.542: [GC pause (young), 0.01526403 secs]
   [Eden: 512M(500M)->0B(510M) Survivors: 0B->2048K Heap: 3018M(4096M)->2506M(4096M)]
 [Times: user=0.09 sys=0.00, real=0.02 secs] 
61812.793: [GC pause (young) (initial-mark), 0.01391544 secs]
   [Eden: 510M(510M)->0B(508M) Survivors: 2048K->4096K Heap: 3016M(4096M)->2508M(4096M)]
 [Times: user=0.09 sys=0.00, real=0.01 secs] 
61812.807: [GC concurrent-root-region-scan-start]

这是使用Java Hotspot 1.7.0_7版本,具有以下有趣的设置:

-XX:PermSize=128m
-XX:MaxPermSize=128m
-XX:NewSize=512m
-XX:MaxNewSize=512m
-Xms4096m
-Xmx4096m
-XX:+UnlockDiagnosticVMOptions
-XX:+UnsyncloadClass
-XX:+UseTLAB
-XX:+UseG1GC
-XX:SurvivorRatio=10
-Xloggc:./workspace/gc.log
-verbose:gc
-XX:+PrintGC
-XX:+PrintGCTimeStamps
-XX:+PrintGCDetails

答案 1

我想你知道这个参考此页面也很有用。

当终身制对象(那些在短暂的(年轻)一代中幸存下来的对象)填满分配给它们的空间时,就会发生完整的GC。当出现完整的 GC 时,必须中止正在进行的任何临时标记。

降低终身发电的填充速率需要添加更多堆/RAM,或者处理终身空间和年轻空间之间可用内存的划分。参数 ,和 用于后者。实验是找到可行的方法的唯一方法。NewSizeMaxNewSizeNewRatio

普遍的看法是,改变比例以使终身世代更大,可以减少完整收藏的数量。在许多情况下,这是正确的,但并非总是如此。有一种情况是,许多终身制对象在被终身保有后不久就死了。換句話說,他們應該在年輕的地區被收集起來,但他們的生命結束有點太遲了。在这种情况下,让年轻一代变得更大,可以让这些物品被收集在那里,而不是被终身监禁。这种情况的症状是已满收集导致分配的空间大幅减少。

这似乎不是你的情况:.您唯一的办法可能是使堆更大,根据需要购买更多内存。尽管如此,几乎所有运行时间较长的系统都会偶尔拥有完整的集合。2978M->2498M


答案 2