CMS-concurrent-preclean abort 是否会导致耗时的 CMS-concurrent-sweep 执行？答案

【问题标题】：Is it CMS-concurrent-preclean abort causing time consuming execution of CMS-concurrent-sweep?CMS-concurrent-preclean abort 是否会导致耗时的 CMS-concurrent-sweep 执行？
【发布时间】：2016-01-14 18:24:08
【问题描述】：

java-版本

java 版本 "1.6.0_21" Java(TM) SE Runtime Environment (build 1.6.0_21-b07) Java HotSpot(TM) 64 位服务器 VM（内部版本 17.0-b17，混合模式）

jvm 配置：

-服务器 -XX:+DoEscape分析 -XX:+CMSParallelRemarkEnabled -XX:+UseBiasedLocking -XX:ParallelGCThreads=20 -XX:+UseLargePages -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:+CMSConcurrentMTEnabled -XX:幸存者比率=8 -XX:目标幸存者比率=90 -XX:MaxTenuringThreshold=15 -XX:ReservedCodeCacheSize=128m -XX:+UseCodeCacheFlushing -XX:新比率=3 -XX:+DisableExplicitGC -Dsun.rmi.dgc.client.gcInterval=1800000 -Dsun.rmi.dgc.server.gcInterval=1800000 -Djava.net.preferIPv4Stack=true -Xss1024k -Xms8192m -Xmx8192m -XX:MaxPermSize=1024m -XX:PermSize=1024m -Dremoting.bind_by_host=false -Dorg.jboss.resolver.warning=true -Dclient.encoding.override=UTF-8 -Dfile.encoding=UTF-8 -Dnet.sf.ehcache.skipUpdateCheck=true -Dorg.apache.xerces.xni.parser.XMLParserConfiguration=org.apache.xerces.parsers.XIncludeAwareParserConfiguration

-Djavax.xml.parsers.DocumentBuilderFactory=org.apache.xerces.jaxp.DocumentBuilderFactoryImpl -详细：gc -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+HeapDumpOnOutOfMemoryError -Djava.net.preferIPv4Stack=true -Dorg.apache.el.parser.COERCE_TO_ZERO=false -Dorg.apache.catalina.connector.Request.SESSION_ID_CHECK=false

32163.991: [CMS-concurrent-mark-start]
32165.339: [CMS-concurrent-mark: 1.318/1.347 secs] [Times: user=6.49 sys=0.39, real=1.35 secs] 
32165.339: [CMS-concurrent-preclean-start]
32165.370: [CMS-concurrent-preclean: 0.030/0.031 secs] [Times: user=0.03 sys=0.00, real=0.03 secs] 
32165.370: [CMS-concurrent-abortable-preclean-start]  CMS: abort preclean due to time 32170.796: [CMS-concurrent-abortable-preclean:
3.737/5.426 secs] [Times: user=10.70 sys=0.31, real=5.43 secs] 
32170.873: [GC[YG occupancy: 754283 K (1887488 K)]32170.873: [Rescan (parallel) , 0.1046140 secs]32170.978: [weak refs processing,
0.0612460 secs] [1 CMS-remark: 5824525K(6291456K)] 6578809K(8178944K), 0.1700560 secs] [Times: user=1.51 sys=0.02, real=0.17 secs] 
32171.100: [CMS-concurrent-sweep-start]
32173.805: [GC 32173.805: [ParNew: 1887488K->209664K(1887488K), 0.3380510 secs] 6928845K->5305271K(8178944K), 0.3385670 secs] [Times: user=1.25 sys=0.05, real=0.34 secs] 
32176.970: [GC 32176.970: [ParNew: 1887488K->209664K(1887488K), 0.1728610 secs] 5660997K->4005785K(8178944K), 0.1734010 secs] [Times: user=1.09 sys=0.10, real=0.17 secs] 
32179.315: [CMS-concurrent-sweep: 6.088/8.215 secs] [Times: user=48.00 sys=2.80, real=8.22 secs] 
32179.315: [CMS-concurrent-reset-start]
32179.507: [CMS-concurrent-reset: 0.192/0.192 secs] [Times: user=1.51 sys=0.22, real=0.19 secs]

CMS-concurrent-preclean abort 是否会导致 CMS-concurrent-sweep 的执行耗时？会不会给用户造成 48 秒的世界停止体验？从上面的 gc 日志推断是什么。

【问题讨论】：

标签： jboss garbage-collection jvm concurrent-mark-sweep

【解决方案1】：

所有以CMS-concurrent-* 表示的阶段，顾名思义，都是并发的，因此不是 STW 暂停。 CMS Initial Mark 和 CMS Final Remark 是并发循环引起的暂停。当然，young gen 收集器有自己的 STW 暂停
user=xxx 与time 命令的输出具有相同的语义。它指的是调度进程的核心时间，它与经过的壁时间有很大关系。如果您对 STW 暂停的持续时间感兴趣，您正在寻找real。

从上面的 gc 日志推断是什么。

该 GC 日志中可见的最长 STW 暂停持续 340 毫秒。

这也可以使用-XX:+PrintGCApplicationConcurrentTime 设置更明确地记录。您可能还想查看GCViewer，它可以更轻松地分析这些日志。

旁注：如果您担心性能，您可能想要升级您的 JVM，随着时间的推移，jit 已经得到了改进。逃逸分析在 1.6 中几乎没有作用（只有锁定省略，没有 SA）

【讨论】：