CMS 回收器的历史
CMS 垃圾回收器早就过时了，现在都流行 G1、ZGC 垃圾回收器了！学这个东西一点用都没有！
CMS 垃圾回收器于 JDK1.5 时期推出，在 JDK9 中被废弃，在 JDK14 中被移除。 而用来替换 CMS 垃圾回收器的便是我们常说的 G1 垃圾回收器。
CMS 回收器简介
CMS（Concurrent Mark Sweep）垃圾回收器是第一个关注 GC 停顿时间的垃圾收集器。 在这之前的垃圾回收器，要么就是串行垃圾回收方式，要么就是关注系统吞吐量。这样的垃圾回收器对于强交互的程序很不友好，而 CMS 垃圾回收器的出现，则打破了这个尴尬的局面。因此，CMS 垃圾回收器诞生之后就受到了大家的欢迎，导致现在还有非常多的应用还在继续使用它。
而 CMS 垃圾回收器通过三色标记算法，实现了垃圾回收线程与用户线程并发执行，从而极大地降低了系统响应时间，提高了强交互应用程序的体验。
初始标记
并发标记
重新标记
并发清除
初始标记，指的是寻找所有被 GCRoots 引用的对象，该阶段需要「Stop the World」。 这个步骤仅仅只是标记一下 GC Roots 能直接关联到的对象，并不需要做整个引用的扫描，因此速度很快。
并发标记，指的是对「初始标记阶段」标记的对象进行整个引用链的扫描，该阶段不需要「Stop the World」。 对整个引用链做扫描需要花费非常多的时间，因此通过垃圾回收线程与用户线程并发执行，可以降低垃圾回收的时间，从而降低系统响应时间。这也是 CMS 垃圾回收器能极大降低 GC 停顿时间的核心原因，但这也带来了一些问题，即：并发标记的时候，引用可能发生变化，因此可能发生漏标（本应该回收的垃圾没有被回收）和多标（本不应该回收的垃圾被回收）了。
重新标记，指的是对「并发标记」阶段出现的问题进行校正，该阶段需要「Stop the World」。 正如并发标记阶段说到的，由于垃圾回收算法和用户线程并发执行，虽然能降低响应时间，但是会发生漏标和多标的问题。所以对于 CMS 回收器来说，它需要这个阶段来做一些校验，解决并发标记阶段发生的问题。
并发清除，指的是将标记为垃圾的对象进行清除，该阶段不需要「Stop the World」。 在这个阶段，垃圾回收线程与用户线程可以并发执行，因此并不影响用户的响应时间。
CMS 之所以能极大地降低 GC 停顿时间，本质上是将原本冗长的引用链扫描进行切分。通过 GC 线程与用户线程并发执行，加上重新标记校正的方式，减少了垃圾回收的时间。
CMS 回收器优缺点
对 CPU 资源消耗较大。 CMS 回收器在并发标记和并发清理阶段，是需要启用多个线程进行处理的，这就意味着它需要占用一部分线程资源，即 CPU 资源。默认情况下 CMS 启用的垃圾回收线程数是，当 CPU 数量越大时，启用的垃圾回收线程数占比就越小。
无法处理浮动垃圾。 由于 CMS 并发标记阶段会发生漏标的情况，因此会有一些本该回收的垃圾对象无法被回收。此外，在 CMS 进行并发清理的时候，用户线程同时在运行，也会产生一些浮动垃圾。因此对于 CMS 回收器来说，其需要留出一些空间给这些浮动垃圾存储。
如果在 CMS 运行期间发现预留的内存无法满足程序需要，就会提示「Concurrent Mode Failure」错误。此时虚拟机采用后备方案：临时启用 Serial Old 回收器来重新进行老年代的垃圾回收，这时候 Stop the World 的时间可能就会很长了。
产生空间碎片。 由于 CMS 是基于「标记-清除」算法实现的回收器，因此其会产生很多空间碎片，这会导致给大对象分配的时候很麻烦，会提前触发 Full GC。为了解决这个问题，CMS 回收器提供了 参数来解决这个问题，意思是在空间不够的时候进行空间整理，这个参数默认是打开的。
总结
CMS 回收器，诞生于 JDK1.5，失落于 JDK9，卒于 JDK14。它的诞生，开启了垃圾回收器专注于优化 GC 停顿时间的历史，随后的 G1、ZGC 都在 CMS 的基础之上改进、优化而来。
而 CMS 回收器之所以能实现对 GC 停顿时间的强力控制，全都归功于对于「根可达算法」的优化。其将串行的引用链扫描，拆分成了「初始标记」和「并发标记」两个阶段，从而极大地降低了 GC 停顿时间，最后再通过「重新标记」解决了并发执行产生的问题。