为什么并发标记和清除（CMS）没有像Full GC那样清理相同数量的内存？

时间：2015-12-23 08:15:27

标签： java garbage-collection heap-memory concurrent-mark-sweep

我的一台生产机器出现了一个奇怪的问题。它托管一个执行CMS（并发标记和扫描）的Java应用程序，但它只清理了旧一代的一小部分。我怀疑内存泄漏并尝试了堆转储。但堆转储之前的Full GC几乎清除了所有旧代。发生了什么？我从未见过Java垃圾收集的这种行为。通常情况下，CMS和Full GC应该收集大约相同数量的垃圾，现在CMS保持大约10GB以上。

  • Java 1.7.0_75
  • Linux Cent OS 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]**

相同的应用程序在使用Cent 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

更新：问题仍未解决。我已经尝试了一切：更新操作系统包和内核，将Java更新到最新版本的Java 1.7.0_80，回滚应用程序版本，但没有成功。

我还验证过以前的GC日志，发现此问题并非永远存在。它在部署后大约一个月前开始。

4 个答案:

答案 0 :(得分：3)

我怀疑由于堆积很大，你的应用程序还没有出现Major collection的需要：终身Old Gen和Survivor Space都没有用尽。

如果您没有想到，（即使满足任一条件，主要收集也未被触发），请分享您的gclog语句。

另外注意：由于您使用的是大堆，因此首选G1GC。

修改 

-XX:CMSInitiatingOccupancyFraction=70 -XX:+UseCMSInitiatingOccupancyOnly

默认情况下，CMS GC使用一组启发式规则来触发垃圾回收。这使得GC不太可预测，并且通常会延迟收集，直到老一代几乎被占用。

-XX:+UseCMSInitiatingOccupancyOnly阻止使用GC启发式。

-XX:CMSInitiatingOccupancyFraction在触发CMS时通知Java VM。

您已将其配置为70％。如果您的OldGen [Max heap（29G） - 新Gen（3G）]接触到70％的限制，GC将被触发。作为GC的一部分，将触发第一个次要GC。如果次要GC没有释放足够的空间来在该时刻分配新对象，则会触发Major GC或Full GC。

有关详细信息，请查看此article。

我找到了另一个相关的SE问题：CMS garbage collector - when does it run?。也看看这个。

答案 1 :(得分：3)

CMS默认情况下不会在JDK 7中卸载类。
您必须指定-XX:+CMSClassUnloadingEnabled，或者更好地切换到JDK 8.

顺便说一句，如果你运行jmap没有live参数，它就不会在创建堆转储之前调用Full GC。

答案 2 :(得分：3)

因此，您可能会遇到一些可能的问题，我会首先说明可能的快速解决方案，然后列出一些您应该考虑长期做的最佳做法。

  1. 可能快速修复：＆＃34; CMS: abort preclean due to time＆＃34;输入您的日志表明您的CMS收集器未在最终的 stop-the-world 完整GC阶段之前正确调整以完成它的工作。基本上，此日志消息的含义是预扫描阶段超时，CMS收集器的其他步骤无法运行。中止预清洁阶段的时间默认值为5秒，这似乎是您的日志中的情况。考虑将这个时间增加到10秒钟，然后观察会发生什么。您应该可以通过添加参数-XX:CMSMaxAbortablePrecleanTime=10000来完成此操作。见Misamitsu's blog entry on the CMSMaxAbortablePrecleanTime tuning parameter。另外，根据我从Stas' blog entry on the subject可以看到的内容，单位是毫秒，而不是秒。

    2. 从长远来看，尝试这些长期的事情：

    1. 如果可以，请尝试使用G1GC收集器。您正在使用Java 7，因此如果您可以在当前环境中尝试使用它。它意味着大堆的表现。
    2. 由于部署和回滚而发生的事实并不起作用，这表明我：
      • 您的整个应用（例如JVM调整参数）不会作为部署的一部分被捕获，或者......
      • 性能问题的原因与您的应用无关。也许您的两个生产主机和在一个主机上运行的不相关的应用程序（例如不同的防病毒版本）之间的差异使您的垃圾收集器的生活变得更加困难。再次，如果你可以，部署到完全相同的硬件和软件。
    3. 评估您是否真的需要这么大的堆。请记住，堆越大，垃圾收集器占用的时间越长，无论您是否使用CMS等并发收集器。
    4. 你有很多调整参数，我会挑战你需要大部分参数。考虑运行基准测试实验，您只需删除-XX:NewSize=3000m，-XX:SurvivorRatio=8，-XX:CMSInitiatingOccupancyFraction=70，-XX:+UseCMSInitiatingOccupancyOnly，-Dsun.rmi.dgc.client.gcInterval=0x7FFFFFFFFFFFFFFE和-Dsun.rmi.dgc.server.gcInterval=0x7FFFFFFFFFFFFFFE参数，然后查看是否存在你的情况有所改善。

      5. 我希望有所帮助，如果需要，请与后续问题进行评论。

答案 3 :(得分：2)

这就是为什么会发生这种情况的原因。看来当你尝试heap dump时，它正在调用方法dumpHeap()。例如，VisualVM在进行堆转储之前会触发完整的GC。

来自documentation：

  

void dumpHeap(String outputFile, boolean live) throws IOException

     

以与hprof堆转储相同的格式将堆转储到outputFile文件。   如果从另一个进程远程调用此方法，则堆转储输出将写入运行目标VM的计算机上名为outputFile的文件。如果outputFile是相对路径，则它相对于启动目标VM的工作目录。

     

参数：

     

outputFile - 依赖于系统的文件名

     

live - 如果true，则仅转储活动对象，即可从其他人访问的对象

为什么？

当您尝试查找内存泄漏时，您不希望获得没有引用的对象（不是垃圾回收）。

建议

我看到一个相当大的堆，可能最好使用 G1 。

  

G1的第一个重点是为运行需要大堆且GC延迟有限的应用程序的用户提供解决方案。这意味着堆大小约为6GB或更大，稳定且可预测的暂停时间低于0.5秒。

请查看documentation中的推荐部分。

相关问题
最新问题