0

java版本

java 版本 "1.6.0_21" Java(TM) SE Runtime Environment (build 1.6.0_21-b07) Java HotSpot(TM) 64-Bit Server VM (build 17.0-b17, 混合模式)

jvm配置：

-server -XX:+DoEscapeAnalysis -XX:+CMSParallelRemarkEnabled -XX:+UseBiasedLocking -XX:ParallelGCThreads=20 -XX:+UseLargePages -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:+CMSConcurrentMTEnabled -XX:SurvivorRatio=8 - XX:TargetSurvivorRatio=90 -XX:MaxTenuringThreshold=15 -XX:ReservedCodeCacheSize=128m -XX:+UseCodeCacheFlushing -XX:NewRatio=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。parser.XIncludeAwareParserConfiguration

-Djavax.xml.parsers.DocumentBuilderFactory=org.apache.xerces.jaxp.DocumentBuilderFactoryImpl -verbose: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 日志推断是什么。

4

1 回答 1

1

  • 顾名思义，所有表示的阶段CMS-concurrent-*都是并发的，因此不是 STW 暂停。CMS Initial Mark并且CMS Final Remark是由并发循环引起的暂停。当然，年轻一代收集器有自己的 STW 暂停

  • user=xxxtime与命令的输出具有相同的语义。它指的是调度进程的核心时间，它与经过的壁时间有很大关系。real如果您对 STW 暂停的持续时间感兴趣，您正在寻找的就是您要查找的内容。

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

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

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

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

于 2016-01-14T20:10:51.333 回答