Question

java -version

java版“1.6.0_21”Java（TM）SE运行时环境（构建 1.6.0_21-b07）Java HotSpot（TM）64位服务器VM（内置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 =128米   -XX：+ UseCodeCacheFlushing   -XX：NewRatio = 3   -XX：+ DisableExplicitGC   -Dsun.rmi.dgc.client.gcInterval = 1800000   -Dsun.rmi.dgc.server.gcInterval = 1800000   -Djava.net.preferIPv4Stack =真   -Xss1024k   -Xms8192m   -Xmx8192m   -XX：MaxPermSize参数=1024米   -XX：PermSize =1024米   -Dremoting.bind_by_host = FALSE   -Dorg.jboss.resolver.warning =真   -Dclient.encoding.override = UTF-8   -Dfile.encoding = UTF-8   -Dnet.sf.ehcache.skipUpdateCheck =真   -Dorg.apache.xerces.xni.parser.XMLParserConfiguration = org.apache.xerces.parsers.XIncludeAwareParserConfiguration

-Djavax.xml.parsers.DocumentBuilderFactory = org.apache.xerces.jaxp.DocumentBuilderFactoryImpl   -verbose：GC   -XX：+ PrintGCDetails -XX：+ PrintGCTimeStamps -XX：+ HeapDumpOnOutOfMemoryError   -Djava.net.preferIPv4Stack =真   -Dorg.apache.el.parser.COERCE_TO_ZERO = FALSE   -Dorg.apache.catalina.connector.Request.SESSION_ID_CHECK =假

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并发 - 预清除是否会导致耗时的CMS并发扫描执行？它会对用户造成48秒的世界停止体验吗？以上gc日志的推断是什么。

Answer 1

所有表示为CMS-concurrent-*的阶段，如名称所示，是并发的，因此不是STW暂停。 CMS Initial Mark和CMS Final Remark是由并发周期引起的暂停。当然年轻的收藏家有自己的STW暂停
user=xxx与time命令的输出具有相同的语义。它指的是安排过程的核心时间，它与经过的时间非常相关。如果您对STW暂停的持续时间感兴趣，real就是您所寻找的。

上述gc日志的推断是什么。

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

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

旁注：如果您担心性能问题，可能需要升级JVM，随着时间的推移会有jit改进。逃逸分析几乎没有回到1.6（只有锁定省略，而不是SA）

是CMS并发 - 预清除中止导致CMS并发扫描的执行耗时吗？

1 个答案: