CMS GC

Concurrent Mark Sweep (CMS) 收集器是为喜欢更短的垃圾收集暂停并且能够在应用程序运行时与垃圾收集器共享处理器资源的应用程序而设计的。

通常，具有相对较大的长期数据集（大型老一代）并在具有两个或更多处理器的机器上运行的应用程序往往会从使用此收集器中受益。CMS 收集器通过命令行选项启用 -XX:+UseConcMarkSweepGC。

Mark Sweep 指的是标记 - 清除算法。

分为以下四个流程：

• 初始标记：仅仅只是标记一下 GC Roots 能直接关联到的对象，速度很快，需要停顿。
• 并发标记：进行 GC Roots Tracing 的过程，它在整个回收过程中耗时最长，不需要停顿。
• 重新标记：为了修正并发标记期间因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录，需要停顿。
• 并发清除：不需要停顿。

在整个过程中耗时最长的并发标记和并发清除过程中，收集器线程都可以与用户线程一起工作，不需要进行停顿。

具有以下缺点：

• 吞吐量低：低停顿时间是以牺牲吞吐量为代价的，导致 CPU 利用率不够高。

• 无法处理浮动垃圾，可能出现 Concurrent Mode Failure。浮动垃圾是指并发清除阶段由于用户线程继续运行而产生的垃圾，这部分垃圾只能到下一次 GC 时才能进行回收。由于浮动垃圾的存在，因此需要预留出一部分内存，意味着 CMS 收集不能像其它收集器那样等待老年代快满的时候再回收。如果预留的内存不够存放浮动垃圾，就会出现 Concurrent Mode Failure，这时虚拟机将临时启用 Serial Old 来替代 CMS。

• 标记 - 清除算法导致的空间碎片，往往出现老年代空间剩余，但无法找到足够大连续空间来分配当前对象，不得不提前触发一次 Full GC。

• https://docs.oracle.com/javase/8/docs/technotes/guides/vm/gctuning/cms.html