Java JVMCMS垃圾收集问题

我在使用并发标记扫描收集器的应用程序的GC日志文件上看到以下症状：

4031.248: [CMS-concurrent-preclean-start]
4031.250: [CMS-concurrent-preclean: 0.002/0.002 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
4031.250: [CMS-concurrent-abortable-preclean-start]
 CMS: abort preclean due to time 4036.346: [CMS-concurrent-abortable-preclean: 0.159/5.096 secs] [Times: user=0.00 sys=0.01, real=5.09 secs] 
4036.346: [GC[YG occupancy: 55964 K (118016 K)]4036.347: [Rescan (parallel) , 0.0641200 secs]4036.411: [weak refs processing, 0.0001300 secs]4036.411: [class unloading, 0.0041590 secs]4036.415: [scrub symbol & string tables, 0.0053220 secs] [1 CMS-remark: 16015K(393216K)] 71979K(511232K), 0.0746640 secs] [Times: user=0.08 sys=0.00, real=0.08 secs] 

预清洁过程不断中止。我尝试将CMSMaxAbortablePrecleanTime从默认的5秒调整到15秒，但没有效果。当前的JVM选项如下所示

Djava.awt.headless=true
 -Xms512m
 -Xmx512m
 -Xmn128m
 -XX:MaxPermSize=128m
 -XX:+HeapDumpOnOutOfMemoryError
 -XX:+UseParNewGC
 -XX:+UseConcMarkSweepGC
 -XX:BiasedLockingStartupDelay=0
 -XX:+DoEscapeAnalysis
 -XX:+UseBiasedLocking
 -XX:+EliminateLocks
 -XX:+CMSParallelRemarkEnabled
 -verbose:gc
 -XX:+PrintGCTimeStamps
 -XX:+PrintGCDetails
 -XX:+PrintHeapAtGC
 -Xloggc:gc.log
 -XX:+CMSClassUnloadingEnabled
 -XX:+CMSPermGenPrecleaningEnabled
 -XX:CMSInitiatingOccupancyFraction=50
 -XX:ReservedCodeCacheSize=64m
 -Dnetworkaddress.cache.ttl=30
 -Xss128k

似乎并发可中止预清理从未运行过。我读了一遍，其中有一个建议是在评论之前启用CMSSCavengee，但暂停的副作用似乎并不理想。有人能提供一些建议吗

此外，我还想知道是否有人有一个很好的参考来浏览CMS GC日志，特别是这一行：

[1 CMS-remark: 16015K(393216K)] 71979K(511232K), 0.0746640 secs]

不清楚这些数字指的是什么记忆区域。 编辑找到指向此的链接

[次数：用户=0.00系统=0.01，实际=5.09秒]

我将尝试调查为什么

CMS并发中止预清洁启动
无法在5秒内获得用户和系统CPU时间

我的建议是从“干净”的JVMCMS启动标志开始，如

-Djava.awt.headless=true
-Xms512m
-Xmx512m
-Xmn128m
-Xss128k
-XX:MaxPermSize=128m
-XX:+UseConcMarkSweepGC
-XX:+HeapDumpOnOutOfMemoryError
-Xloggc:gc.log
-XX:+PrintGCTimeStamps
-XX:+PrintGCDetails
-XX:+PrintHeapAtGC

然后检查问题是否再次出现，并一次调整一个参数。
正如有人已经提到的，第一步是增加CMSinitiatingOccinecyFaction

作为第二步，我将使用标志
-XX:-PrintTenuringDistribution
，确保年轻一代不会过早晋升到老一代。这将导致从旧到新的引用，这可能导致更长的可中止预清洁阶段。
如果有这样一个过早的提升，试着调整eden和survior空间之间的比例。
对于这种现象有一个很好的解释：

引述：

因此，当系统负载较轻时（这意味着没有
次要gc），预清洗将始终超时，完全gc将始终超时
失败。cpu是浪费

它不会失败。它将不那么并行（即效率较低，并且
暂停时间更长，工作更少）

总而言之：这似乎是正常的操作-线程只需等待5秒钟的小GC发生，但如果不发生，则没有什么大问题：JVM选择不同的（效率较低的）策略来继续GC。
cms标记用于引用内容管理系统，而不是并发标记和扫描GC。我会删除它。哎哟，很抱歉，对我来说，将CMS设置为50%似乎有点低：-XX:CMSInitiatingOccupancyFraction=50可能增加它（或者使用“反垃圾邮件”建议的默认值）会有不同的表现。此外，我的日志通常会在CMS之前、期间和之后运行它们。ParNew在运行吗？