CMS通过并发标记清除减少停顿，但存在并发模式失败与浮动垃圾问题，因不整理内存导致碎片化，需依赖Full GC补救。
CMS垃圾收集器，或者我们常说的Concurrent Mark Sweep，它存在的目的很直接：尽可能减少应用线程暂停（Stop-The-World, STW）的时间。它通过让大部分垃圾回收工作与应用线程并发执行来实现这一点，但代价是会消耗额外的CPU资源，并且可能产生内存碎片。
解决方案
CMS垃圾收集器的工作过程，从我的经验来看，可以大致分解为几个关键阶段，每个阶段都有其独特的作用和对应用的影响。
1. 初始标记（Initial Mark） 这个阶段是STW的。它很短，主要任务是标记所有直接被GC Roots引用的对象，以及年轻代中存活的对象所引用的老年代对象。你可以把它想象成给所有“根”对象打上一个快速的标签，为后续的并发标记提供起点。
2. 并发标记（Concurrent Mark） 这是CMS最核心，也是耗时最长的阶段。在这个阶段，GC线程和应用线程是并发运行的。GC线程会从初始标记阶段标记的对象开始，遍历整个老年代对象图，标记所有可达的对象。由于应用线程也在同时运行，对象引用关系可能会发生变化。CMS通过“增量更新”（Incremental Update）机制来处理这些变化，当一个对象引用发生改变时，会记录下来（通过卡片标记，Card Marking）。
3. 并发预清理（Concurrent Preclean） 这个阶段也是并发的。它主要是为了处理在并发标记阶段，由于应用线程活动而导致的对象引用变化。它会扫描在并发标记阶段被标记为“脏”的卡片，重新扫描这些区域，标记那些在并发标记阶段结束后新变得可达的对象。这个阶段的目的，就是尽量减少下一个STW阶段——重新标记的工作量。有时候，我甚至觉得这个阶段有点像在为接下来的大考做预习，把能做的提前做了。
4. 重新标记（Remark） 这是一个STW阶段，但通常比初始标记稍微长一些。它的任务是再次扫描堆，修正并发标记和并发预清理阶段中，由于应用线程活动而遗漏或标记错误的对象。它会处理剩余的“脏”卡片，并遍历年轻代，确保所有老年代中可达的对象都被正确标记。这个阶段虽然短暂，但对确保回收的准确性至关重要，它就像是最终的检查，确保没有遗漏。
5. 并发清理（Concurrent Sweep） 这个阶段同样是并发的。GC线程会遍历整个老年代，回收那些在标记阶段结束后仍然是不可达（即未被标记）的对象所占据的内存空间。值得注意的是，CMS在清理时并不会进行内存碎片整理，它只是将这些空间标记为可用，并通过一个空闲列表（free-list）来管理。这是CMS的一个特点，也是它后续会遇到一些麻烦的根源。
为什么CMS GC会引入“并发模式失败”？
“并发模式失败”（Concurrent Mode Failure）是CMS GC一个让人头疼的问题，在我看来，它直接暴露了CMS并发设计中的一个核心矛盾。简单来说，CMS GC的并发清理阶段，虽然不暂停应用，但它并不会整理内存碎片。这意味着，随着时间推移，老年代的空闲内存会变得越来越分散，形成很多小的、不连续的内存块。
当应用需要分配一个较大的对象，而老年代中又找不到足够大的连续空闲内存块时，CMS GC就会触发“并发模式失败”。此时，CMS会放弃当前的并发回收，转而执行一次Full GC。而这次Full GC通常是使用Stop-The-World的Serial Old收集器来完成的，它会彻底暂停所有应用线程，并且会进行内存整理。想象一下，你正在高速公路上开车，突然被告知要临时改道去走一段泥泞小路，而且所有车都得停下来等，那种感觉就是“并发模式失败”带来的体验。
这种失败的根本原因，在于应用分配速度过快，或者CMS GC启动得太晚，导致在并发清理完成之前，老年代就已经被填满，或者碎片化严重到无法满足新的分配需求。参数
CMSInitiatingOccupancyFraction就是为了缓解这个问题而存在的，它允许我们提前启动CMS GC，给它更多时间去完成工作，避免这种尴尬的局面。但即便如此，也无法完全避免，因为碎片化始终是CMS的一个伴生问题。
CMS的“浮动垃圾”问题是怎样产生的，又意味着什么？
“浮动垃圾”（Floating Garbage）是CMS GC并发特性带来的另一个不可避免的副作用。它指的是那些在并发标记阶段已经开始，但在这个阶段中途变为不可达的对象。因为CMS的并发标记和清理是与应用线程同时进行的，当一个对象在并发标记阶段被判断为可达，但在并发清理阶段开始之前，它又被应用线程解除了所有引用，变成了垃圾。
问题就在于，CMS在并发清理时，只会回收那些在标记阶段结束后依然被标记为不可达的对象。对于这些在并发标记过程中“意外”变成垃圾的对象，CMS在当前周期内是无法识别并回收的。它们就像是漂浮在海面上的垃圾，虽然已经无用，但要等到下一个潮汐（下一次GC周期）才能被冲走。
这意味着什么呢？首先，它会导致内存的临时浪费。这些浮动垃圾会一直占据着内存空间，直到下一次CMS GC周期才会被回收。虽然通常量不大，但在内存吃紧的场景下，可能会稍微增加老年代的内存压力。其次，这表明CMS并不是一个“实时”的垃圾收集器，它对垃圾的回收存在一定的滞后性。这是为了换取低暂停时间所做的权衡，我们必须接受这一点。毕竟，没有完美的解决方案，只有最适合特定场景的权衡。
CMS垃圾收集器如何处理老年代内存碎片化？
这是一个非常直接的问题，答案也同样直接：CMS垃圾收集器在它的常规并发清理过程中，并不会进行内存碎片整理。它采取的是一种“标记-清除”算法，回收完垃圾后，空闲的内存块会以链表的形式被维护起来，等待新的对象分配。这直接导致了老年代内存碎片化的问题。
那么，CMS真的对碎片化束手无策吗？也不是完全没有办法，但这些办法都带有一定的妥协性。
一种处理方式是，当“并发模式失败”发生时，JVM会退回到Full GC，而Full GC（通常由Serial Old收集器执行）是会进行内存整理的。这意味着，碎片化问题会在系统被迫执行Full GC时得到缓解，但代价是长时间的STW。
另一种是我们可以通过JVM参数进行配置：
UseCMSCompactAtFullCollection。当这个参数被启用时，CMS会在执行Full GC之后，额外进行一次内存碎片整理。这听起来不错，但请注意，它依然是在Full GC之后，这意味着它是在最糟糕的STW时刻进行的操作。同时，
CMSFullGCsBeforeCompaction参数允许你设置在多少次Full GC之后才进行一次内存整理，这可以在一定程度上控制整理的频率，避免每次Full GC都耗费额外的时间去整理。
所以，与其说CMS“处理”碎片化，不如说它在避免不了碎片化的情况下，提供了一些“补救”措施，而且这些补救措施往往伴随着高昂的STW代价。这也是CMS后来逐渐被G1等新一代垃圾收集器取代的重要原因之一，因为G1在设计之初就考虑到了碎片化问题，并尝试在不引入长时间STW的前提下进行内存整理。
