admin 管理员组

文章数量: 1184232

我正在分析 GC 暂停问题，我注意到当 CMS 使用并且并发模式失败或手动触发 GC
（通过 System.gc( )) 使用的 STW 收集器似乎不是并行的。
（我知道 ExplicitGCInvokesConcurrent 标志，但它不会解决并发故障）。
我尝试使用 -XX:ParallelGCThreads=… -XX:ParallelCMSThreads=… 但它们似乎没有效果。

我是从下面的 GC 日志行中推断出来的

24.904: [Full GC (System) 24.904: [CMS: 302703K->303056K(2116864K), 1.0847520 secs] 484492K->303056K(2423552K), [CMS Perm : 7528K->7525K(21248K)], 1.0852780 secs] [Times: user=1.04 sys=0.02, real=1.09 secs]
如果它是并行的，“user”将等于 “nThreads” * “real”。
此外，如果我选择 ParallelOld GC，它将正确运行。

我真的不明白为什么CMS的故障转移STW机制不是并行的，不是应该尽快完成工作吗？

您是正确的，并发模式失败会串行执行Full GC。
用于 UseParallelGC/UseParallelOldGC 的 parallel old collector 从未移植到 CMS。由于 UseParallelGC 和 CMS 之间的差异，它的工作量超出了我们的预期。

我认为 G1 的行为也一样（AFAIK G1 的后备收集器是从 CMS 复制的）

是的，G1 的行为相同。 G1 不会将 UseParallelGC 实现用于并行完整收集，但会实现符合 G1 设计的一个。 目前，G1 团队一直专注于实现暂停目标和避免完整收集的更好策略。 最后我听说在并行完整收集之前，至少有一些工作需要完成类卸载（JEP 156）。

本文标签： 退到 模式 收集器 Concurrent CMS

版权声明：本文标题：CMS 并发模式失效（Concurrent mode failure）回退到 serial old 收集器 内容由网友自发贡献，该文观点仅代表作者本人， 转载请联系作者并注明出处：http://roclinux.cn/b/1763934076a3279848.html， 本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，一经查实，本站将立刻删除。