Java 连续CMS收集，随后出现并发模式故障

我的Java应用程序的GC日志指示连续CMS GC，随后出现并发模式故障，停止回收几乎整个堆的world集合

为什么CMS系列无法清除旧一代？为什么并发模式故障需要停止world collection

在并发模式故障最终迫使停止清除空间的world collection之前，像下面这样的CMS集合连续发生了几天。请注意，CMS集合几乎不恢复任何空间，而升级失败后的集合将旧一代从1.92 GB减少到50.7 MB

旧代对象是否由永久代中的已死亡、未收集的对象保持活动状态，这些对象在STW收集过程中被丢弃？我是否应该考虑使用xxx：+csCaseBunDeulink来解决这个问题？

在GC日志中完成CMS收集：

2014-06-10T22:54:45.999-0700: 4999434.771: [GC [1 CMS-initial-mark: 1920327K(1926784K)] 2050302K(2080128K), 0.3369430 secs] [Times: user=0.34 sys=0.00, real=0.33 secs] 
2014-06-10T22:54:46.338-0700: 4999435.111: [CMS-concurrent-mark-start]
2014-06-10T22:54:50.543-0700: 4999439.315: [CMS-concurrent-mark: 4.204/4.204 secs] [Times: user=4.21 sys=0.08, real=4.20 secs] 
2014-06-10T22:54:50.543-0700: 4999439.315: [CMS-concurrent-preclean-start]
2014-06-10T22:54:50.573-0700: 4999439.345: [CMS-concurrent-preclean: 0.023/0.030 secs] [Times: user=0.02 sys=0.00, real=0.04 secs] 
2014-06-10T22:54:50.573-0700: 4999439.346: [CMS-concurrent-abortable-preclean-start]
2014-06-10T22:54:54.599-0700: 4999443.371: [GC2014-06-10T22:54:54.599-0700: 4999443.372:    [ParNew
Desired survivor size 8716288 bytes, new threshold 6 (max 6)
- age   1:    1410440 bytes,    1410440 total
- age   2:     181888 bytes,    1592328 total
- age   3:     117864 bytes,    1710192 total
- age   4:     136792 bytes,    1846984 total
- age   5:     161296 bytes,    2008280 total
- age   6:    2488416 bytes,    4496696 total
: 141989K->5449K(153344K), 0.1317090 secs] 2062317K->1925911K(2080128K), 0.1321970 secs]    [Times: user=0.23 sys=0.01, real=0.14 secs] 
 CMS: abort preclean due to time 2014-06-10T22:54:55.606-0700: 4999444.378: [CMS-concurrent-abortable-preclean: 2.600/5.033 secs] [Times: user=2.88 sys=0.08, real=5.03 secs] 
2014-06-10T22:54:55.611-0700: 4999444.384: [GC[YG occupancy: 10356 K (153344 K)]2014-06-10T22:54:55.612-0700: 4999444.384: [Rescan (parallel) , 0.1665620 secs]2014-06-10T22:54:55.778-0700: 4
999444.550: [weak refs processing, 0.0000440 secs]2014-06-10T22:54:55.778-0700: 4999444.551: [scrub string table, 0.0010220 secs] [1 CMS-remark: 1920462K(1926784K)] 1930818K(2080128K), 0.1678710 secs] [Times: user=0.28 sys=0.00, real=0.17 secs] 
2014-06-10T22:54:55.780-0700: 4999444.552: [CMS-concurrent-sweep-start]
2014-06-10T22:54:57.554-0700: 4999446.326: [CMS-concurrent-sweep: 1.775/1.775 secs]    [Times: user=1.82 sys=0.01, real=1.78 secs] 
2014-06-10T22:54:57.554-0700: 4999446.327: [CMS-concurrent-reset-start]
2014-06-10T22:54:57.564-0700: 4999446.336: [CMS-concurrent-reset: 0.009/0.009 secs] [Times: user=0.01 sys=0.01, real=0.01 secs]

并发模式故障GC日志：

2014-06-10T22:56:18.793-0700: 4999527.565: [GC [1 CMS-initial-mark: 1920286K(1926784K)] 2051254K(2080128K), 0.3388330 secs] [Times: user=0.33 sys=0.00, real=0.33 secs] 
2014-06-10T22:56:19.132-0700: 4999527.904: [CMS-concurrent-mark-start]
2014-06-10T22:56:23.112-0700: 4999531.884: [CMS-concurrent-mark: 3.976/3.980 secs] [Times: user=4.07 sys=0.04, real=3.99 secs] 
2014-06-10T22:56:23.112-0700: 4999531.885: [CMS-concurrent-preclean-start]
2014-06-10T22:56:23.141-0700: 4999531.914: [CMS-concurrent-preclean: 0.022/0.029 secs] [Times: user=0.01 sys=0.01, real=0.03 secs] 
2014-06-10T22:56:23.141-0700: 4999531.914: [CMS-concurrent-abortable-preclean-start]
2014-06-10T22:56:26.242-0700: 4999535.014: [GC2014-06-10T22:56:26.242-0700: 4999535.014: [ParNew2014-06-10T22:56:26.256-0700: 4999535.028: [CMS-concurrent-abortable-preclean: 1.948/3.114 secs] [Times: user=1.93 sys=0.12, real=3.11 secs] 
 (promotion failed)
Desired survivor size 8716288 bytes, new threshold 6 (max 6)
- age   1:    1036320 bytes,    1036320 total
- age   2:     825248 bytes,    1861568 total
- age   3:     119024 bytes,    1980592 total
- age   4:     113784 bytes,    2094376 total
- age   5:     129024 bytes,    2223400 total
- age   6:     154976 bytes,    2378376 total
: 141769K->140729K(153344K), 0.3807730 secs]2014-06-10T22:56:26.623-0700: 4999535.395: [CMS
 (concurrent mode failure): 1920816K->50773K(1926784K), 28.3938140 secs] 2062055K->50773K(2080128K), [CMS Perm : 48657K->41071K(262144K)], 28.7750370 secs] [Times: user=1.65 sys=0.03, real=28.78 secs] 

Java版本：

$ /usr/java/jdk1.7.0_51/bin/java -version
java version "1.7.0_51"
Java(TM) SE Runtime Environment (build 1.7.0_51-b13)
Java HotSpot(TM) 64-Bit Server VM (build 24.51-b03, mixed mode)

JVM选项：

-Xms2048m
-Xmx2048m
-XX:PermSize=256m
-XX:MaxPermSize=256m
-XX:+UseConcMarkSweepGC
-XX:+PrintClassHistogram
-XX:+DisableExplicitGC
-XX:+PrintGCDateStamps
-XX:+PrintGCDetails
-XX:+PrintTenuringDistribution
-XX:+HeapDumpOnOutOfMemoryError
-XX:HeapDumpPath=<logs dir>
-Xloggc:<log path>

---

垃圾收集收集死对象/空引用。这里使用的策略是低暂停。以下是应用程序环境中可能发生的事情

理由1：

应用程序可能使用分配的堆进行对象分配，这反过来会导致java堆内存不足，无法进一步分配。在这种情况下，增加java堆将有助于为进一步的请求分配对象

理由2：

如果设置的Xmx值是应用程序运行的最佳值，则应用程序环境中可能发生内存泄漏，从而导致java堆占用垃圾收集器无法清除的对象

内存泄漏可以通过以下方法识别。 添加-verbose:gcjvm参数并收集gc日志。收集日志后，在下面的工具中加载gc日志 有关内存泄漏的更多信息，请参阅下文。