面试官：今天还是来聊聊CMS垃圾收集器呗？

系统管理员 2024-04-08 12:07 63阅读 0赞

**面试官**：**今天还是来聊聊CMS垃圾收集器呗？**

**候选者**：嗯啊…

**候选者**：如果用Seria和Parallel系列的垃圾收集器：在垃圾回收的时，用户线程都会完全停止，直至垃圾回收结束！

![7c82931a18ab4b71934bdc20f2557f30.png][]

**候选者**：CMS的全称：Concurrent Mark Sweep，翻译过来是「并发标记清除」

**候选者**：用CMS对比上面的垃圾收集器(Seria和Parallel和parNew)：它最大的不同点就是「并发」：在GC线程工作的时候，用户线程「不会完全停止」，用户线程在「部分场景下」与GC线程一起并发执行。

**候选者**：但是，要理解的是，无论是什么垃圾收集器，Stop The World是一定无法避免的！

**候选者**：CMS只是在「部分」的GC场景下可以让GC线程与用户线程并发执行

**候选者**：CMS的设计目标是为了避免「老年代 GC」出现「长时间」的卡顿（Stop The World）

![a448dbfd315941b08f89cfcb16c8d46f.png][]

**面试官**：**那你清楚CMS的工作流程吗？**

**候选者**：只了解一点点，不能多了。

**候选者**：CMS可以简单分为5个步骤：初始标记、并发标记、并发预清理、重新标记以及并发清除

**候选者**：从步骤就不难看出，CMS主要是实现了「标记清除」垃圾回收算法

**面试官**：嗯…是的

**候选者**：我就从「初始标记」来开始吧

**候选者**：「初始标记」会标记GCRoots「直接关联」的对象以及「年轻代」指向「老年代」的对象

**候选者**：「初始标记」这个过程是会发生Stop The World的。但这个阶段的速度算是很快的，因为没有「向下追溯」（只标记一层）

![594b8b86ab6a4abe9ad318f35623bd02.png][]

**候选者**：在「初始标记」完了之后，就进入了「并发标记」阶段啦

**候选者**：「并发标记」这个过程是不会停止用户线程的（不会发生 Stop The World）。这一阶段主要是从GC Roots向下「追溯」，标记所有可达的对象。

**候选者**：「并发标记」在GC的角度而言，是比较耗费时间的（需要追溯）

![edde733c5f144bcd8c2d64d5f7d12e6f.png][]

**候选者**：「并发标记」这个阶段完成之后，就到了「并发预处理」阶段啦

**候选者**：「并发预处理」这个阶段主要想干的事情：希望能减少下一个阶段「重新标记」所消耗的时间

**候选者**：因为下一个阶段「重新标记」是需要Stop The World的

**面试官**：嗯…

**候选者**：「并发标记」这个阶段由于用户线程是没有被挂起的，所以对象是有可能发生变化的

**候选者**：可能有些对象，从新生代晋升到了老年代。可能有些对象，直接分配到了老年代（大对象）。可能老年代或者新生代的对象引用发生了变化…

**面试官**：**那这个问题，怎么解决呢？**

**候选者**：针对老年代的对象，其实还是可以借助类card table的存储（将老年代对象发生变化所对应的卡页标记为dirty）

**候选者**：所以「并发预处理」这个阶段会扫描可能由于「并发标记」时导致老年代发生变化的对象，会再扫描一遍标记为dirty的卡页

**面试官**：嗯…

**候选者**：对于新生代的对象，我们还是得遍历新生代来看看在「并发标记」过程中有没有对象引用了老年代..

**候选者**：不过JVM里给我们提供了很多「参数」，有可能在这个过程中会触发一次 minor GC（触发了minor GC 是意味着就可以更少地遍历新生代的对象）

![39f571062cad445e81efc7a1340cf493.png][]

**候选者**：「并发预处理」这个阶段阶段结束后，就到了「重新标记」阶段

**候选者**：「重新标记」阶段会Stop The World，这个过程的停顿时间其实很大程度上取决于上面「并发预处理」阶段（可以发现，这是一个追赶的过程：一边在标记存活对象，一边用户线程在执行产生垃圾）

![1c1ef377cf25497895f6fe9ec8b81605.png][]

**候选者**：最后就是「并发清除」阶段，不会Stop The World

**候选者**：一边用户线程在执行，一边GC线程在回收不可达的对象

**候选者**：这个过程，还是有可能用户线程在不断产生垃圾，但只能留到下一次GC 进行处理了，产生的这些垃圾被叫做“浮动垃圾”

**候选者**：完了以后会重置 CMS 算法相关的内部数据，为下一次 GC 循环做准备

![5aac1a69222248c1bd9805b3eb54b40a.png][]

**面试官**：嗯，CMS的回收过程，我了解了

**面试官**：**听下来，其实就是把垃圾回收的过程给”细分”了，然后在某些阶段可以不停止用户线程，一边回收垃圾，一边处理请求，来减少每次垃圾回收时 Stop The World的时间**

**面试官**：当然啦，中间也做了很多的优化（dirty card标记、可能中途触发minor gc等等，在我理解下，这些应该都提供了CMS的相关参数配置）

**面试官**：**不过，我看现在很多企业都在用G1了，那你觉得CMS有什么缺点呢？**

**候选者**：1.空间需要预留：CMS垃圾收集器可以一边回收垃圾，一边处理用户线程，那需要在这个过程中保证有充足的内存空间供用户使用。

**候选者**：如果CMS运行过程中预留的空间不够用了，会报错（Concurrent Mode Failure），这时会启动 Serial Old垃圾收集器进行老年代的垃圾回收，会导致停顿的时间很长。

**候选者**：显然啦，空间预留多少，肯定是有参数配置的

**候选者**：2. 内存碎片问题：CMS本质上是实现了「标记清除算法」的收集器（从过程就可以看得出），这会意味着会产生内存碎片

**候选者**：由于碎片太多，又可能会导致内存空间不足所触发full GC，CMS一般会在触发full GC这个过程对碎片进行整理

**候选者**：整理涉及到「移动」/「标记」，那这个过程肯定会Stop The World的，如果内存足够大（意味着可能装载的对象足够多），那这个过程卡顿也是需要一定的时间的。

**面试官**：嗯…

![c519743c229546bf9abc6a3dd22aeedc.png][]

**候选者**：使用CMS的弊端好像就是一个死循环：

**候选者**：1. 内存碎片过多，导致空间利用率减低。

**候选者**：2. 空间本身就需要预留给用户线程使用，现在碎片内存又加剧了空间的问题，导致有可能垃圾收集器降级为Serial Old，卡顿时间更长。

**候选者**：3. 要处理内存碎片的问题（整理），同样会卡顿

**候选者**：不过，技术实现就是一种trade-off（权衡），不可能你把所有的事情都做得很完美

**候选者**：了解这个过程，是非常有趣的

**面试官**：那G1垃圾收集器你了解吗

**候选者**：只了解一点点，不能多了

**候选者**：不过，留到下次吧，先让你消化下，不然怕你顶不住了。

**本文总结**：

*  **CMS垃圾回收器设计目的**：为了避免「老年代 GC」出现「长时间」的卡顿（Stop The World）
 *  **CMS垃圾回收器回收过程**：初始标记、并发标记、并发预处理、重新标记和并发清除。初始标记以及重新标记这两个阶段会Stop The World
 *  **CMS垃圾回收器的弊端**：会产生内存碎片&&需要空间预留：停顿时间是不可预知的![548351a75ed24fb2a41c28d9e073909f.png][]![4c35e9df0fd0445d97631fd149948996.png][]

[7c82931a18ab4b71934bdc20f2557f30.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/08/3260cf4672154150b1f7127fa0ca5b06.png
[a448dbfd315941b08f89cfcb16c8d46f.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/08/c83d25f9bddb47d58a593783c70c742a.png
[594b8b86ab6a4abe9ad318f35623bd02.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/08/818819d37fe14a7c8fab7a28e6306e61.png
[edde733c5f144bcd8c2d64d5f7d12e6f.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/08/11a416beb243429b90c90270b91ccbc6.png
[39f571062cad445e81efc7a1340cf493.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/08/2ad5bab0da1d421facdaa68dd017240d.png
[1c1ef377cf25497895f6fe9ec8b81605.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/08/e523f6f55ee14af7a969c50540ce7a3c.png
[5aac1a69222248c1bd9805b3eb54b40a.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/08/846dedd66d3d436aa851fd0cd80e421f.png
[c519743c229546bf9abc6a3dd22aeedc.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/08/fa4ce23d092c4641881fdfca20f53cdc.png
[548351a75ed24fb2a41c28d9e073909f.png]: https://img-blog.csdnimg.cn/548351a75ed24fb2a41c28d9e073909f.png
[4c35e9df0fd0445d97631fd149948996.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/08/114e8c5cf49d475dac95a737b209b995.png