CMS（Concurrent Mark Sweep）垃圾收集器是以“最短的停顿”著称的垃圾回收器，因此也是 JDK 9 之前使用最广泛的垃圾回收器之一。那么，问题来了，为什么 CMS 能实现最短停顿时间？CMS 垃圾回收器的工作原理又是啥呢？接下来，我们一起来看。

CMS 工作原理

CMS 之所以能实现最短停顿时间是和它的工作原理分不开的，它们存在因果关联关系，因为 CMS 的工作原理，所以决定了 CMS 能实现最短的停顿时间。

“最短停顿时间”指的是垃圾回收过程中，应用程序暂停的时间尽可能短。也就是在垃圾回收时，Stop The World（STW，全局停顿）时间要尽量短，因为只有 STW 够短，那么应用程序才能更快的执行。

那么 CMS 工作原理是啥呢？

CMS 垃圾回收器执行步骤分为以下两步：

1. 标记
2. 清除

而在以上过程中，“标记”阶段是需要大量时间的，反而“清除”需要的时间比较短（因为清除只需要把垃圾对象删除“回收”即可）。

那怎么才能提升整体的执行效率，保证最短的停顿时间呢？

于是 CMS 设计者开始动脑子了，这时候有人就提出：既然“标记”阶段比较费时，那我们就将“标记”阶段分阶段处理好了，并且最好能让他能与应用线程一起执行，这样就不需要 STW（全局停顿）了，那么停顿时间不久短了嘛？

因此 CMS 的设计者将垃圾回收的“标记”阶段，变成了以下 3 个阶段：

1. 初始标记（STW）：只标记和 GC Roots 直接关联的对象，执行速度很快。
2. 并发标记（和用户线程并发执行）：GC Roots 直接关联的对象继续往下（一直）遍历和标记，耗时会比较长。
3. 重新标记（STW）：对上一步“并发标记”阶段因为用户线程执行，而导致变动的对象进行修正标记。

具体执行流程如下：

在整个标记的过程中，只有初始标记和重新标记需要 STW，但是初始标记只标记和 GC Roots 直接关联的对象，而重新标记只是对“并发标记”阶段的用户线程进行修正标记，因此这两个阶段执行的时间都很短，所以整个 STW 停顿时间也就很短。

并且为了让 CMS 能够拥有更短的停顿时间，所以在“标记”阶段完成之后，CMS 采用的是并发清除策略，也就是 GC 垃圾回收线程和用户线程一起执行，这样就不需要 STW 了，所以执行效率就更高了。

CMS 完整执行流程如下：

1. 初始标记（STW）：只标记和 GC Roots 直接关联的对象，执行速度很快。
2. 并发标记（和用户线程并发执行）：GC Roots 直接关联的对象继续往下（一直）遍历和标记，耗时会比较长。
3. 重新标记（STW）：对上一步“并发标记”阶段因为用户线程执行，而导致变动的对象进行修正标记。
4. 并发清除（和用户线程并发执行）：使用并发-清除算法将垃圾对象进行清除。

执行流程如下图所示：

课后思考

虽然 CMS 能实现最短停顿时间，但它也存在一些缺点，例如：会内存碎片的问题。那为什么它会有内存碎片的问题？又怎么能解决内存碎片的问题？

本文已收录到我的面试小站 [www.javacn.site](https://www.javacn.site)，其中包含的内容有：Redis、JVM、并发、并发、MySQL、Spring、Spring MVC、Spring Boot、Spring Cloud、MyBatis、设计模式、消息队列等模块。