CMS垃圾收集

初始标记

需要暂停所有的其他线程，但这个阶段会很快完成。它的目的是标记所有的根对象，以及被根对象直接引用的对象，以及年轻代指向老年代的对象，不会遍历对象关系，单线程执行。

并发标记阶段

不需要暂停应用线程，遍历对象图，标记可达对象。
可能产生漏标记的问题，会导致本该存活的对象被回收。如何解决这个问题？
在老年代对象引用关系改变的时候，把该对象所在的卡页标记为脏页（通过写屏障维护卡表），后续只需要扫描脏页而不是整个老年代。这个是CMS解决并发标记漏标的具体实现方案。

并发预处理阶段

不需要暂停应用线程。
会扫描脏页的对象并遍历标记，然后清除脏标记。

可取消的并发预处理

为什么在可取消的并发预处理进行一次年轻代GC能减轻最终标记的工作？
如果一直没等到Minor GC，这个时候进行最终标记的话，可能会发生连续停顿，假设重新标记的时候新生代发生了Minor GC（STW），最终标记又是STW的，因此可能会发生连续停顿。

CMS提供了参数CMSScavengeBeforeRemark，使最终标记前强制进行一次Minor GC。

这个参数有利有弊，利是降低了Remark阶段的停顿时间，弊的是在新生代对象很少的情况下也多了一次YGC，哪怕在可取消的并发预处理阶段已经发生了一次YGC，然后在该阶段又会去傻傻的触发一次。

重新标记

不暂停应用程序。因为它循环做同样的事情，直到满足某个退出条件。
1.处理 From 和 To 区的对象，标记可达的老年代对象。
2.和上一个阶段一样，扫描处理Dirty Card中的对象。

在重新标记（Remark）阶段，实际上是要扫描整个堆内存的，包括新生代和老年代。

这是因为在并发标记阶段，应用程序线程还在运行，可能会有新对象被分配到新生代，并且可能会有引用关系的改变。如果不扫描新生代，就可能会漏掉一些被引用的对象，导致误删。

但是实际上，由于各种优化技术，比如增量更新（Incremental Update）和卡表(Card Table)，重新标记阶段可以只扫描部分区域。例如，只需要扫描在并发标记阶段中被修改过的那部分堆内存区域，而无需全盘扫描整个堆内存。

年轻代的扫描可以使用卡表？就是用上记录老年代到年轻代引用关系的卡表？

重新标记也是可以并发执行的。

可以通过-XX:ParallelRemarkEnabled，参数启用并行重新标记，它允许在重新标记阶段使用多线程。

请注意，这个选项不影响初始标记阶段，那个阶段仍将使用单线程执行。

启用-XX:ParallelRemarkEnabled参数并行执行CMS的重新标记阶段可以减少垃圾回收时应用的停止时间，但也有可能带来一些缺点：

资源消耗：并行执行需要更多的CPU资源，如果系统上运行着其他需要CPU的任务，这可能会降低它们的性能。
复杂性增加：并行化处理通常增加了系统的复杂性，可能会导致更难预测和调试的性能问题。
不稳定性：尽管并行重新标记通常可以提高效率，但在某些特定硬件和工作负载下，可能会得到相反的结果。
因此，是否使用-XX:ParallelRemarkEnabled取决于具体的应用和硬件环境。在开启这个选项之前，最好先在仿真环境中进行充分的测试，以评估它对性能的影响。

并发清除

最后是并发清除阶段，在此阶段中，垃圾回收器删除未被标记的对象，并回收他们占用的内存空间，同样，该步骤也是与应用线程并发执行的。

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

CMS使用空闲列表（free-list），在并发清除阶段结束后，CMS会将未被标记的内存（即垃圾对象占据的内存）收集起来，组成一个空闲列表。

这个空闲列表保存了可用于新对象分配的内存块信息。当需要分配新对象时，JVM可以直接从空闲列表中找到合适大小的内存块进行分配，而无需进行完整的垃圾回收。

但是，这种方法也有其缺点，例如可能会导致内存碎片化问题。如果连续的空闲内存块不足以满足新的内存请求，就需要触发一次完全的垃圾收集，此时则可能会引起较长时间的暂停。

缺点

1.CMS垃圾收集器是处理器资源敏感的。在并发阶段，它不会导致用户线程停顿，但会占用一部分线程（或者说处理器的计算能力）来进行垃圾回收，从而导致应用程序变慢，降低总吞吐量。低延迟和高吞吐，往往无法同时达成，低延迟有时是牺牲高吞吐换得的。
CMS 回收线程数量可以通过-XX:ParallelCMSThreads=这个JVM参数来设定。

2.无法处理浮动垃圾。并发清理阶段，用户线程是还在继续运行的，程序在运行自然就还会伴随有新的垃圾对象不断产生。CMS无法在当次收集中处理掉它们，只能下一次垃圾回收来处理。

3.在垃圾收集阶段用户线程还需要持续运行，那就还需要预留足够内存空间提供给用户线程使用，因此CMS收集器不能像其他收集器那样等待到老年代几乎完全被填满了再进行收集。可以通过 -XX:CMSInitiatingOccupancyFraction 参数自行调节进行CMS回收的内存阈值。

如果CMS运行期间预留的内存无法满足程序分配新对象的需要，就会出现一次并发失败（Concurrent Mode Failure）。会触发触发STW，临时启用Serial Old收集器来重新进行老年代的垃圾收集，但这样停顿时间就很长了。Serial Old使用的是标记-整理（Mark-Compact）算法。

4.内存碎片可能导致Full GC。
空间碎片过多时，将会给大对象分配带来很大麻烦，往往会出现老年代还有很多剩余空间，但就是无法找到足够大的连续空间来分配当前对象，而不得不提前触发一次Full GC的情况。
CMS收集器提供了一个-XX：+UseCMS-CompactAtFullCollection，用于在CMS收集器不得不进行Full GC时开启内存碎片的合并整理过程，但是整理过程又必须移动存活对象，这样空间碎片问题是解决了，但停顿时间又会变长。

另外一个参数-XX：CMSFullGCsBefore-Compaction，这个参数的作用是要求CMS收集器在执行过若干次（数量由参数值决定）不整理空间的Full GC之后，下一次进入Full GC前会先进行碎片整理。虽然内存压缩可以减少内存碎片，提高内存利用效率，但同时也会增加GC的暂停时间。

问题

1.Full GC指的是什么？
CMS GC是指老年代的GC，而Full GC指的是整个堆的GC事件，包括新生代、老年代、元空间等

参考

CMS
CMS