Question

2013-11-26T10:19:30.011+0800: [GC [ParNew: 2432484K->19997K(2696640K), 0.0378270 secs] 5560240K->3155822K(7691712K), 0.0398670 secs] [Times: user=0.18 sys=0.00, real=0.04 secs] 
2013-11-26T10:19:36.277+0800: [GC [ParNew: 2417093K->15777K(2696640K), 0.0372550 secs] 5552917K->3151795K(7691712K), 0.0388490 secs] [Times: user=0.28 sys=0.00, real=0.04 secs] 
**2013-11-26T10:19:36.325+0800: [GC [ParNew: 20441K->16452K(2696640K), 0.0186420 secs] 3156459K->3153092K(7691712K), 0.0200280 secs] [Times: user=0.17 sys=0.00, real=0.02 secs]** 
2013-11-26T10:19:41.464+0800: [GC [ParNew: 2413508K->22811K(2696640K), 0.0426440 secs] 5550148K->3160128K(7691712K), 0.0444710 secs] [Times: user=0.25 sys=0.00, real=0.04 secs]

显然，小gc每5或6秒发生一次。

在2013-11-26T10：19：36.277之后，2013-11-26T10：19：36.325有一个小gc，只使用了20441K !!!

为什么小gc发生了（线上的blod）？谁知道？

更多细节：

这种现象每24小时不会超过10次。

有关我们服务器的更多详细信息：

CPU计数12个CPU

CPU速度2400 MHz

内存总计16322984 KB

jvm（热点1.6.0_26）的参数是：

-Xms7804M -Xmx7804M -Xmn2926M -XX：PermSize = 256M -XX：MaxPermSize = 256M -XX：SurvivorRatio = 8 -XX：TargetSurvivorRatio = 70 -XX：MaxTenuringThreshold = 10 -server -Xss256k -XX：+ HeapDumpOnOutOfMemoryError -XX ：+ PrintGCDetails -XX：+ PrintGCDateStamps -XX：+ UseConcMarkSweepGC -XX：+ DisableExplicitGC -XX：SoftRefLRUPolicyMSPerMB = 0 -XX：CMSInitiatingOccupancyFraction = 75 -XX：+ UseCMSInitiatingOccupancyOnly -XX：ParallelGCThreads = 12 -XX：+ CMSScavengeBeforeRemark -XX：+ CMSClassUnloadingEnabled

@Alexey Ragozin更多日志：

2013-11-27T23:34:47.352+0800: [GC [ParNew: 2496458K->81521K(2696640K), 0.0381510 secs]     5104803K->2690529K(7691712K), 0.0406260 secs] [Times: user=0.28 sys=0.00, real=0.04 secs] 
2013-11-27T23:34:51.745+0800: [GC [ParNew: 2478577K->57599K(2696640K), 0.0535680 secs] 5087585K->2716762K(7691712K), 0.0554400 secs] [Times: user=0.28 sys=0.01, real=0.06 secs] 
2013-11-27T23:34:55.728+0800: [GC [ParNew: 2454747K->19841K(2696640K), 0.0300150 secs] 5113910K->2679701K(7691712K), 0.0320030 secs] [Times: user=0.18 sys=0.00, real=0.03 secs] 
**2013-11-27T23:34:55.769+0800: [GC [ParNew: 21438K->16389K(2696640K), 0.0171200 secs] 2681299K->2676788K(7691712K), 0.0187850 secs] [Times: user=0.13 sys=0.00, real=0.02 secs]** 
2013-11-27T23:34:59.888+0800: [GC [ParNew: 2413445K->16017K(2696640K), 0.0251400 secs] 5073844K->2676744K(7691712K), 0.0271570 secs] [Times: user=0.15 sys=0.00, real=0.02 secs] 
2013-11-27T23:35:04.374+0800: [GC [ParNew: 2413073K->16059K(2696640K), 0.0240360 secs] 5073800K->2677460K(7691712K), 0.0259960 secs] [Times: user=0.15 sys=0.00, real=0.03 secs] 
... ...
2013-11-28T02:56:57.719+0800: [GC [ParNew: 2449927K->45500K(2696640K), 0.0360740 secs] 6195838K->3791742K(7691712K), 0.0379370 secs] [Times: user=0.23 sys=0.00, real=0.03 secs] 
2013-11-28T02:57:37.987+0800: [GC [ParNew: 2442556K->54097K(2696640K), 0.0383490 secs] 6188798K->3800678K(7691712K), 0.0402170 secs] [Times: user=0.23 sys=0.00, real=0.04 secs] 
2013-11-28T02:57:38.036+0800: [GC [1 CMS-initial-mark: 3746580K(4995072K)] 3801777K(7691712K), 0.0694940 secs] [Times: user=0.06 sys=0.00, real=0.07 secs] 
2013-11-28T02:57:38.770+0800: [CMS-concurrent-mark: 0.661/0.662 secs] [Times: user=2.15 sys=0.00, real=0.66 secs] 
2013-11-28T02:57:38.806+0800: [CMS-concurrent-preclean: 0.035/0.035 secs] [Times: user=0.06 sys=0.01, real=0.04 secs] 
 CMS: abort preclean due to time 2013-11-28T02:57:43.862+0800: [CMS-concurrent-abortable-preclean: 5.016/5.056 secs] [Times: user=6.82 sys=0.19, real=5.05 secs] 
**2013-11-28T02:57:43.872+0800: [GC[YG occupancy: 407766 K (2696640 K)]2013-11-28T02:57:43.872+0800: [GC [ParNew: 407766K->35780K(2696640K), 0.0236470 secs] 4154346K->3782623K(7691712K), 0.0256460 secs] [Times: user=0.20 sys=0.00, real=0.03 secs]** 
[Rescan (parallel) , 0.0119390 secs][weak refs processing, 0.8478360 secs][class unloading, 0.0661530 secs][scrub symbol & string tables, 0.0146780 secs] [1 CMS-remark: 3746843K(4995072K)] 3782623K(7691712K), 1.1138910 secs] [Times: user=1.41 sys=0.00, real=1.12 secs] 
2013-11-28T02:57:48.965+0800: [CMS-concurrent-sweep: 3.893/3.977 secs] [Times: user=5.65 sys=0.15, real=3.97 secs] 
2013-11-28T02:57:48.977+0800: [CMS-concurrent-reset: 0.012/0.012 secs] [Times: user=0.02 sys=0.00, real=0.02 secs]

Answer 1

-XX:+CMSScavengeBeforeRemark是您奇怪的小集合的原因。

CMS必须进行2次世界停留以完成旧的空间收集周期

初始标记
备注

他们都需要扫描整个年轻空间。年轻人收藏后，年轻空间中的物品数量非常少，因此在收集年轻品后，旧的空间收集暂停了。

一旦CMS准备好暂停评论，

-XX:+CMSScavengeBeforeRemark选项会强制收集年轻人，即使Eden尚未满员。

你会在每个旧的空间收集周期中看到这个“现象”。

有关CMS机制的更多详细信息 - Understanding GC pauses in JVM, HotSpot's CMS collector
有关JVM GC选项的更多信息 - HotSpot JVM garbage collection options cheat sheet

UPDATE
从技术上讲，还有另一个原因可能导致年轻的早产儿。如果应用程序试图分配不适合Eden的大型数组，JVM可能会开始收集空闲空间。这是可能的，但更有可能的是JVM会选择直接在旧空间中分配这个数组。

Answer 2

我怀疑除了编写和/或维护特定GC的人之外，任何人都能正确/正确地解释这种现象。

但是，我会发现你的应用程序正在创造大量的垃圾。每6秒2400000K == 2.4Gb的垃圾。你有一个病态的应用程序，或者这是一个非常不现实的垃圾收集器基准测试......它不会告诉你有关GC如何为实际应用程序行事的任何有意义的事情。

如果您仅仅为了满足您的好奇心而提出此问题，我建议您自己调查此现象......然后将结果作为自我答案报告。

Answer 3

当年轻一代填满时会发生轻微的地方选区。如果遵循，以高速率创建新对象的应用程序将经历越来越多的次要垃圾收集。鉴于您发布的GC日志，您的应用程序也可以看到相同的行为。您可以高速创建对象，从而经常触发较小的GC。

有关GC的更多信息，您可以查看此资源：http://www.oracle.com/webfolder/technetwork/tutorials/obe/java/gc01/index.html

奇怪的次要gc发生在正常的次要gc之后

3 个答案: