CMS垃圾收集器的几个过程

最新推荐文章于 2025-06-05 10:21:17 发布

转载最新推荐文章于 2025-06-05 10:21:17 发布 · 2.5k 阅读

java 专栏收录该内容

66 篇文章

订阅专栏

本文详细解析了CMS垃圾回收器的工作原理及其各个阶段的过程，包括触发条件、不同阶段的任务执行及参数配置等内容。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

首先理解下Major GC,Full GC和CMS的区别：

1. Full GC == Major GC指的是对老年代/永久代的stop the world的GC

2. Full GC的次数 = 老年代GC时 stop the world的次数

3. Full GC的时间 = 老年代GC时 stop the world的总时间

4. CMS 不等于Full GC，我们可以看到CMS分为多个阶段，只有stop the world的阶段被计算到了Full GC的次数和时间，而和业务线程并发的GC的次数和时间则不被认为是Full GC

5. Full GC本身不会先进行Minor GC，我们可以配置，让Full GC之前先进行一次Minor GC，因为老年代很多对象都会引用到新生代的对象，先进行一次Minor GC可以提高老年代GC的速度。比如老年代使用CMS时，设置CMSScavengeBeforeRemark优化，让CMS remark之前先进行一次Minor GC。

当使用CMS收集器时，当开始进行收集时，old代的收集过程如下所示：

1，首先jvm根据-XX:CMSInitiatingOccupancyFraction，-XX:+UseCMSInitiatingOccupancyOnly来决定什么时间开始垃圾收集；

2，如果设置了-XX:+UseCMSInitiatingOccupancyOnly，那么只有当old代占用确实达到了-XX:CMSInitiatingOccupancyFraction参数所设定的比例时才会触发cms gc；

3，如果没有设置-XX:+UseCMSInitiatingOccupancyOnly，那么系统会根据统计数据自行决定什么时候触发cms gc；因此有时会遇到设置了80%比例才cms gc，但是50%时就已经触发了，就是因为这个参数没有设置的原因；

4，当cms gc开始时，首先的阶段是CMS-initial-mark，此阶段是初始标记阶段，是stop the world阶段，因此此阶段标记的对象只是从root集最直接可达的对象；

CMS-initial-mark：961330K（1572864K），指标记时，old代的已用空间和总空间

5，下一个阶段是CMS-concurrent-mark，此阶段是和应用线程并发执行的，所谓并发收集器指的就是这个，主要作用是标记可达的对象

此阶段会打印2条日志：CMS-concurrent-mark-start，CMS-concurrent-mark

6，下一个阶段是CMS-concurrent-preclean，此阶段主要是进行一些预清理，因为标记和应用线程是并发执行的，因此会有些对象的状态在标记后会改变，此阶段正是解决这个问题因为之后的Rescan阶段也会stop the world，为了使暂停的时间尽可能的小，也需要preclean阶段先做一部分工作以节省时间

此阶段的部分工作：标记新进入old区的对象（新晋升，新分配），以及在并发阶段被修改了的对象。

此阶段会打印2条日志：CMS-concurrent-preclean-start，CMS-concurrent-preclean

7，下一阶段是CMS-concurrent-abortable-preclean阶段，加入此阶段的目的是使cms gc更加可控一些，作用也是执行一些预清理，以减少Rescan阶段造成应用暂停的时间

此阶段的工作为：

可中断的并发预清理阶段：

-在并发预清理完成后开始

-策略如下：

当前新生代< 2M，直接启动remark，跳过该阶段，这时候需要扫描的新生代对象少

> 2M && < 50%, 说明刚执行完ygc不久，已经在ygc时stw一次了，为了让remark的stw与上一次有间隔，所以此时等待新生代占用>50%后中断

> 50%，等待一次ygc，时间最长默认为5s，不管是否发生ygc都中断，等待remark准备ok可以随时被中断

另提供CMSScavengeBeforeRemark参数，使remark前强制进行一次YGC

2M (默认值)参数：CMSScheduleRemarkEdenSizeThreshold