CMS（Concurrent Mark Sweep）垃圾收集器是以“最短的停顿”著称的垃圾回收器，因此也是 JDK 9 之前使用最广泛的垃圾回收器之一。那么，问题来了，为什么 CMS 能实现最短停顿时间？CMS 垃圾回收器的工作原理又是啥呢？接下来，我们一起来看。
CMS 工作原理
CMS 之所以能实现最短停顿时间是和它的工作原理分不开的，它们存在因果关联关系，因为 CMS 的工作原理，所以决定了 CMS 能实现最短的停顿时间。
“最短停顿时间”指的是垃圾回收过程中，应用程序暂停的时间尽可能短。也就是在垃圾回收时，Stop The World（STW，全局停顿）时间要尽量短，因为只有 STW 够短，那么应用程序才能更快的执行。
那么 CMS 工作原理是啥呢？
CMS 垃圾回收器执行步骤分为以下两步：
- 标记
- 清除
而在以上过程中，“标记”阶段是需要大量时间的，反而“清除”需要的时间比较短（因为清除只需要把垃圾对象删除“回收”即可）。
那怎么才能提升整体的执行效率，保证最短的停顿时间呢？
于是 CMS 设计者开始动脑子了，这时候有人就提出：既然“标记”阶段比较费时，那我们就将“标记”阶段分阶段处理好了，并且最好能让他能与应用线程一起执行，这样就不需要 STW（全局停顿）了，那么停顿时间不久短了嘛？
因此 CMS 的设计者将垃圾回收的“标记”阶段，变成了以下 3 个阶段：
- 初始标记（STW）：只标记和 GC Roots 直接关联的对象，执行速度很快。
- 并发标记（和用户线程并发执行）：GC Roots 直接关联的对象继续往下（一直）遍历和标记，耗时会比较长。
- 重新标记（STW）：对上一步“并发标记”阶段因为用户线程执行，而导致变动的对象进行修正标记。
具体执行流程如下：
在整个标记的过程中，只有初始标记和重新标记需要 STW，但是初始标记只标记和 GC Roots 直接关联的对象，而重新标记只是对“并发标记”阶段的用户线程进行修正标记，因此这两个阶段执行的时间都很短，所以整个 STW 停顿时间也就很短。
并且为了让 CMS 能够拥有更短的停顿时间，所以在“标记”阶段完成之后，CMS 采用的是并发清除策略，也就是 GC 垃圾回收线程和用户线程一起执行，这样就不需要 STW 了，所以执行效率就更高了。
CMS 完整执行流程如下：
- 初始标记（STW）：只标记和 GC Roots 直接关联的对象，执行速度很快。
- 并发标记（和用户线程并发执行）：GC Roots 直接关联的对象继续往下（一直）遍历和标记，耗时会比较长。
- 重新标记（STW）：对上一步“并发标记”阶段因为用户线程执行，而导致变动的对象进行修正标记。
- 并发清除（和用户线程并发执行）：使用并发-清除算法将垃圾对象进行清除。
执行流程如下图所示：
课后思考
虽然 CMS 能实现最短停顿时间，但它也存在一些缺点，例如：会内存碎片的问题。那为什么它会有内存碎片的问题？又怎么能解决内存碎片的问题？
本文已收录到我的面试小站 www.javacn.site，其中包含的内容有：Redis、JVM、并发、并发、MySQL、Spring、Spring MVC、Spring Boot、Spring Cloud、MyBatis、设计模式、消息队列等模块。
