15个经典面试问题，JVM-GC-耗时频频升高，这次排查完想说

最新推荐文章于 2024-10-18 16:05:34 发布

莫晓前端资料

最新推荐文章于 2024-10-18 16:05:34 发布

阅读量83

点赞数

分类专栏：程序员文章标签：后端 java 面试

本文链接：https://blog.csdn.net/m0_60226911/article/details/119386354

版权

程序员专栏收录该内容

216 篇文章 0 订阅

订阅专栏

箭头1 显示abortable-preclean阶段耗时4.04秒。箭头2 显示的是remark阶段，耗时0.11秒。

虽然abortable-preclean阶段是concurrent的，不会暂停其他的用户线程。就算不优化，可能影响也不大。但是天天收到各个业务线的gc报警，长久来说也不是好事。

在调优之前先看下该应用的GC统计数据，包括GC次数，耗时：

统计期间内(18天)发生CMS GC 69次，其中 abortable preclean阶段平均耗时2.45秒，final remark阶段平均112ms,最大耗时170ms.

4. 优化目标

降低abortable preclean 时间，而且不增加final remark的时间（因为remark是STW的）。

5. JVM参数调优

5.1 第一次调优

先尝试调低abortable preclean阶段的时间，看看效果。

有两个参数可以控制这个阶段何时结束：

-XX:CMSMaxAbortablePrecleanTime=5000 ，默认值5s，代表该阶段最大的持续时间
-XX:CMSScheduleRemarkEdenPenetration=50 ，默认值50%，代表Eden区使用比例超过50%就结束该阶段进入remark

调整为最大持续时间为1s，Eden区使用占比10%，如下：

-XX:CMSMaxAbortablePrecleanTime=1000

-XX:CMSScheduleRemarkEdenPenetration=10

为什么调整成这样两个值，我们是这样考虑的：首先每次CMS都发生在老年代使用占比达到80%时，因为这是由下面两个参数决定的：

-XX:CMSInitiatingOccupancyFraction=80

-XX:+UseCMSInitiatingOccupancyOnly

而老年代的增长是由于部分对象在Minor GC后仍然存活，被晋升到老年代，导致老年代使用占比增长的，也就是在每次CMS GC发生之前刚刚发生过一次Minor GC，所以在那一刻新生代的使用占比是很低的。那么我们预计这个时候尽快结束abortable preclean阶段，在remark时就不需要扫描太多的Eden区对象，remark STW的时间也就不会太长。

调整的思路是这样了，那到底效果如何呢？

第一次调整的的结果

在统计期间（17小时左右）内，发生过2次CMS GC。Abortable Preclean 平均耗时835ms，这是预期内的。但是Final Remark 平均耗时495ms（调整前是112ms），其中一次是80ms，另一次是910ms！将近1秒钟！Remark是STW的！对于要求低延时的应用来说这是无法接受的！

对比这两次CMS GC的详细GC日志，我们发现了一些对分析问题非常有用的东西。

remark耗时80ms的那次GC日志

[YG occupancy: 181274 K (1887488 K)] - 年轻代当前占用情况和总容量

耗时80ms的这次remark发生时（早上9点，非高峰时段），新生代（YG）占用181.274M。

remark耗时910ms的那次GC日志

[YG occupancy: 773427 K (1887488 K)]

耗时910ms的这次remark发生时（晚上10点左右，高峰时段），新生代（YG）占用773.427M。
因为这个时候高峰期，新生代的占用量上升的非常快，几乎同样的时间内，非高峰时段仅上升到181M，但是高峰时段就上升到773M。

这里能得出一个有用的结论：如果abortale preclean阶段时间太短，随后在remark时，新生代占用越大，则remark持续的时间（STW）越长。

这就陷入了两难了，不缩短abortale preclean耗时会报longgc；缩短的话，remark阶段又会变长，而且是STW，更不能接受。

对于这种情况，CMS提供了CMSScavengeBeforeRemark参数，尝试在remark阶段之前进行一次Minor GC，以降低新生代的占用。

-XX:+CMSScavengeBeforeRemark

Enables scavenging attempts before the CMS remark step. By default, this option is disabled.

5.2 第二次调优

调优前的考虑：
增加-XX:+CMSScavengeBeforeRemark 不是没有代价的，因为这会增加一次Minor GC停顿。所以这个方案好或者不好的判断标准就是：增加CMSScavengeBeforeRemark参数之后的minor GC停顿时间 + remark 停顿时间如果比增加之前的remark GC停顿时间要小，这才是好的方案。

第二次调整的结果