为什么并发标记和扫描(CMS)不清理与完全GC相同的内存量？

Question

我的一台生产机器出了个奇怪的问题。它拥有一个执行CMS (并发标记和扫描)的Java应用程序，但是它只清理了老一代的一小部分。我怀疑内存泄漏，并尝试堆转储。但是堆转储之前的完整GC几乎清除了所有的老一代。发生什么事了呢？我从未见过Java垃圾收集的这种行为。通常CMS和全GC应该收集大约相同数量的垃圾，现在CMS保存了大约10 GC的垃圾。

• Java 1.7.0_75
• Linux分操作系统7

GC日志：

**2016-01-04T07:37:40.196+0000: 431200.698: [GC [1 CMS-initial-mark: 21633423K(27336704K)] 22826703K(30101504K), 4.3910840 secs] [Times: user=4.40 sys=0.01, real=4.39 secs] 
2016-01-04T07:37:44.588+0000: 431205.090: [CMS-concurrent-mark-start]
2016-01-04T07:38:08.718+0000: 431229.220: [CMS-concurrent-mark: 18.213/24.131 secs] [Times: user=126.00 sys=2.22, real=24.13 secs] 
2016-01-04T07:38:08.718+0000: 431229.220: [CMS-concurrent-preclean-start]
2016-01-04T07:38:08.843+0000: 431229.345: [CMS-concurrent-preclean: 0.118/0.125 secs] [Times: user=0.29 sys=0.00, real=0.12 secs] 
2016-01-04T07:38:08.843+0000: 431229.345: [CMS-concurrent-abortable-preclean-start]
 CMS: abort preclean due to time 2016-01-04T07:38:13.906+0000: 431234.408: [CMS-concurrent-abortable-preclean: 4.975/5.063 secs] [Times: user=10.18 sys=0.03, real=5.06 secs] 
2016-01-04T07:38:14.001+0000: 431234.503: [GC[YG occupancy: 1312993 K (2764800 K)]2016-01-04T07:38:14.001+0000: 431234.503: [Rescan (parallel) , 4.6981760 secs]2016-01-04T07:38:18.699+0000: 431239.202: [weak refs processing, 0.0002970 secs]2016-01-04T07:38:18.700+0000: 431239.202: [scrub string table, 0.0006900 secs] [1 CMS-remark: 21633423K(27336704K)] 22946417K(30101504K), 4.6993310 secs] [Times: user=105.40 sys=0.36, real=4.70 secs] 
2016-01-04T07:38:18.701+0000: 431239.203: [CMS-concurrent-sweep-start]
2016-01-04T07:38:27.967+0000: 431248.469: [CMS-concurrent-sweep: 9.160/9.267 secs] [Times: user=17.91 sys=0.10, real=9.26 secs] 
2016-01-04T07:38:27.968+0000: 431248.470: [CMS-concurrent-reset-start]
2016-01-04T07:38:28.028+0000: 431248.531: [CMS-concurrent-reset: 0.061/0.061 secs] [Times: user=0.14 sys=0.00, real=0.06 secs]** 
2016-01-04T07:38:30.801+0000: 431251.303: [GC [1 CMS-initial-mark: 21633105K(27336704K)] 23039228K(30101504K), 5.6079370 secs] [Times: user=5.60 sys=0.01, real=5.61 secs] 
2016-01-04T07:38:36.409+0000: 431256.911: [CMS-concurrent-mark-start]
2016-01-04T07:38:54.673+0000: 431275.175: [CMS-concurrent-mark: 17.807/18.264 secs] [Times: user=119.97 sys=1.66, real=18.26 secs] 
2016-01-04T07:38:54.673+0000: 431275.175: [CMS-concurrent-preclean-start]
2016-01-04T07:38:54.799+0000: 431275.301: [CMS-concurrent-preclean: 0.119/0.126 secs] [Times: user=0.25 sys=0.00, real=0.13 secs] 
2016-01-04T07:38:54.799+0000: 431275.301: [CMS-concurrent-abortable-preclean-start]
 CMS: abort preclean due to time 2016-01-04T07:39:01.382+0000: 431281.884: [CMS-concurrent-abortable-preclean: 6.478/6.583 secs] [Times: user=12.23 sys=0.06, real=6.58 secs] 
2016-01-04T07:39:01.487+0000: 431281.989: [GC[YG occupancy: 1596183 K (2764800 K)]2016-01-04T07:39:01.487+0000: 431281.989: [Rescan (parallel) , 3.5737630 secs]2016-01-04T07:39:05.061+0000: 431285.563: [weak refs processing, 0.0002690 secs]2016-01-04T07:39:05.061+0000: 431285.563: [scrub string table, 0.0005740 secs] [1 CMS-remark: 21633105K(27336704K)] 23229288K(30101504K), 3.5747910 secs] [Times: user=80.26 sys=0.27, real=3.58 secs] 
2016-01-04T07:39:05.062+0000: 431285.564: [CMS-concurrent-sweep-start]
2016-01-04T07:39:21.895+0000: 431302.397: [CMS-concurrent-sweep: 9.449/16.834 secs] [Times: user=27.52 sys=0.16, real=16.83 secs] 
2016-01-04T07:39:21.895+0000: 431302.397: [CMS-concurrent-reset-start]
2016-01-04T07:39:21.995+0000: 431302.497: [CMS-concurrent-reset: 0.099/0.099 secs] [Times: user=0.23 sys=0.01, real=0.10 secs] 
2016-01-04T07:39:24.104+0000: 431304.606: [GC [1 CMS-initial-mark: **21631742K(27336704K)**] 23455261K(30101504K), 5.6592940 secs] [Times: user=5.67 sys=0.00, real=5.66 secs] 
2016-01-04T07:39:29.764+0000: 431310.266: [CMS-concurrent-mark-start]
2016-01-04T07:39:56.859+0000: 431337.361: [CMS-concurrent-mark: 19.813/27.096 secs] [Times: user=140.17 sys=2.62, real=27.10 secs] 
2016-01-04T07:39:56.859+0000: 431337.361: [CMS-concurrent-preclean-start]
2016-01-04T07:39:57.102+0000: 431337.604: [CMS-concurrent-preclean: 0.152/0.242 secs] [Times: user=0.35 sys=0.00, real=0.24 secs] 
2016-01-04T07:39:57.102+0000: 431337.604: [CMS-concurrent-abortable-preclean-start]
 CMS: abort preclean due to time 2016-01-04T07:40:03.016+0000: 431343.518: [CMS-concurrent-abortable-preclean: 5.376/5.914 secs] [Times: user=11.65 sys=0.05, real=5.91 secs] 
2016-01-04T07:40:03.016+0000: 431343.518: [GC[YG occupancy: 2045175 K (2764800 K)]2016-01-04T07:40:03.016+0000: 431343.518: [Rescan (parallel) , 3.4843400 secs]2016-01-04T07:40:06.501+0000: 431347.003: [weak refs processing, 0.0002510 secs]2016-01-04T07:40:06.501+0000: 431347.003: [scrub string table, 0.0006220 secs] [1 CMS-remark: **21631742K(27336704K)**] 23676918K(30101504K), 3.4853760 secs] [Times: user=78.31 sys=0.27, real=3.49 secs] 
2016-01-04T07:40:06.502+0000: 431347.004: [CMS-concurrent-sweep-start]
{Heap before GC invocations=1832 (full 5077):
 par new generation   total 2764800K, used 2166647K [0x00000000bae00000, 0x0000000176600000, 0x0000000176600000)
  eden space 2457600K,  77% used [0x00000000bae00000, 0x000000012e6a4c90, 0x0000000150e00000)
  from space 307200K,  89% used [0x0000000150e00000, 0x0000000161939318, 0x0000000163a00000)
  to   space 307200K,   0% used [0x0000000163a00000, 0x0000000163a00000, 0x0000000176600000)
 concurrent mark-sweep generation total 27336704K, used 21631644K [0x0000000176600000, 0x00000007fae00000, 0x00000007fae00000)
 concurrent-mark-sweep perm gen total 49956K, used 30116K [0x00000007fae00000, 0x00000007fdec9000, 0x0000000800000000)
**2016-01-04T07:40:12.775+0000: 431353.277: [Full GC2016-01-04T07:40:12.775+0000: 431353.277: [CMS2016-01-04T07:40:17.924+0000: 431358.426: [CMS-concurrent-sweep: 9.211/11.422 secs] [Times: user=16.59 sys=0.15, real=11.42 secs] 
 (concurrent mode interrupted): 21631644K->4907878K(27336704K), 39.2467600 secs] 23798292K->4907878K(30101504K), [CMS Perm : 30116K->28023K(49956K)], 39.2468730 secs] [Times: user=39.24 sys=0.05, real=39.25 secs]** 

相同的应用程序通常运行在另一台机器上，使用的是分OS 5，java 7。

java -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=1581
-Dcom.sun.management.jmxremote.authenticate=false
-Dcom.sun.management.jmxremote.ssl=false -verbose:gc -XX:+PrintGCDetails
-XX:+UseCompressedOops -XX:+PrintGCDateStamps -XX:+PrintHeapAtGC
-XX:+PrintTenuringDistribution -XX:+UseConcMarkSweepGC
-Xloggc:/usr/local/app/logs/current-gc.log -Xms29g -Xmx29g -XX:NewSize=3000m
-XX:SurvivorRatio=8 -XX:CMSInitiatingOccupancyFraction=70
-XX:+UseCMSInitiatingOccupancyOnly
-Dsun.rmi.dgc.client.gcInterval=0x7FFFFFFFFFFFFFFE
-Dsun.rmi.dgc.server.gcInterval=0x7FFFFFFFFFFFFFFE
-cp /usr/local/app/conf:/usr/local/app/app.jar:/usr/local/app/lib/* -Xdebug
-Xrunjdwp:transport=dt_socket,address=8099,server=y,suspend=n
-Dvisualvm.display.name=App -XX:+HeapDumpOnOutOfMemoryError
-XX:HeapDumpPath=/usr/local/app/logs/
-XX:ErrorFile=/usr/local/app/logs/hs_err_pid%p.log
-Djgroups.tcpgossip.initial_host=localhost
-Dlog4j.hostname=host7.company.com com.company.app.service.App

更新：问题仍未解决。我已经尝试了一切:更新OS包和内核，将Java更新为最新版本的Java1.7.0_80，回滚应用程序版本，但没有成功。

我还验证了以前的GC日志，发现这个问题不是永远存在的。大约一个月前，在一次部署之后，它开始了。

Answer 1

我怀疑您的应用程序中还没有出现对主集合的需求，原因是堆非常大:既没有耗尽终身Old Gen，也没有耗尽Survivor Space。

如果您不这么认为，(即使满足了任何一种条件，也没有触发主要集合)，请与您共享gclog语句。

注意:由于您使用的是大型堆，所以首选使用G1GC。

编辑：

-XX:CMSInitiatingOccupancyFraction=70 -XX:+UseCMSInitiatingOccupancyOnly 

默认情况下，CMS GC使用一组启发式规则来触发垃圾收集。这就降低了GC的可预见性，并且通常会将收集延迟到老一代几乎被占用。

-XX:+UseCMSInitiatingOccupancyOnly防止使用GC启发式方法。

-XX:CMSInitiatingOccupancyFraction通知Java何时应该触发CMS。

您已经将其配置为70%。如果你的OldGen最大堆(29G) -新一代(3G)触及70%的限制，GC将被触发。作为GC的一部分，第一个小GC被触发。如果小GC没有在这个节点释放足够的空间来分配新对象，那么将触发主GC或完整GC。

有关更多细节，请查看此文章。

我发现了另一个相关的SE问题：CMS垃圾收集器-什么时候运行？。也来看看这个。

Answer 2

默认情况下，CMS不会在JDK 7中卸载类。

您必须指定-XX:+CMSClassUnloadingEnabled，或者更好地切换到JDK 8。

顺便说一句，如果不使用jmap参数运行live，那么在创建堆转储之前，它不会调用完整的GC。

Answer 3

因此，有几个可能的原因造成了您的困境，我将首先说明可能的快速修复，然后说明下面的一些最佳实践，您应该考虑在长期内这样做。

1. 可能的快速修复:日志的"CMS: abort preclean due to time“条目表明您的CMS收集器在最终停止世界完整GC阶段之前没有被正确地调优以完成它的工作。基本上，这条日志消息意味着预清洁阶段正在超时，而CMS收集器的进一步步骤无法运行。中止预清理阶段的默认时间是5秒，这似乎是您的日志中的情况。考虑将这一时间增加到10秒左右，并观察发生了什么。您应该能够通过添加参数-XX:CMSMaxAbortablePrecleanTime=10000来做到这一点。见调谐参数。而且，根据我从Stas关于这个主题的博客条目中看到的，单位是毫秒，而不是秒。

从长远的角度来尝试这些长期的事情：

1. 如果可以，可以试试G1GC收集器。您正在使用Java 7，因此，如果您可以在当前环境中使用Java 7，请尝试一下。这是为了表现与大堆。
2. 这是由于部署和回滚不起作用的结果，这对我来说是这样的：
   • 您的整个应用程序(例如JVM调优参数)不会作为部署的一部分捕获，或者.
   • 性能问题的原因与您的应用程序无关。也许您的两个生产主机和一个在一个主机上运行的不相关应用程序(例如不同的防病毒版本)之间的差异使垃圾收集器的生活变得更加困难。因此，如果可以的话，可以部署到完全相同的硬件和软件中。

​

1. 评估您是否真的需要这么大的堆。请记住，堆越大，垃圾收集器所用的时间就越长，无论您是否使用CMS之类的并发收集器。
2. 您有很多调优参数，我会向您提出挑战，您需要其中的大多数参数。考虑运行一个基准测试，您只需删除-XX:NewSize=3000m、-XX:SurvivorRatio=8、-XX:CMSInitiatingOccupancyFraction=70、-XX:+UseCMSInitiatingOccupancyOnly、-Dsun.rmi.dgc.client.gcInterval=0x7FFFFFFFFFFFFFFE和-Dsun.rmi.dgc.server.gcInterval=0x7FFFFFFFFFFFFFFE参数，并查看您的情况是否有所改善。

我希望这会有所帮助，如有需要，请提出跟进问题。