CMS垃圾回收器工作原理详解

欢迎各位小伙伴来到golang学习网，相聚于此都是缘哈哈哈！今天我给大家带来《CMS（Concurrent Mark Sweep）垃圾收集器是Java虚拟机中一种以低延迟为目标的垃圾回收器，主要用于老年代（Old Generation）。它的设计目标是在应用程序运行过程中尽可能减少停顿时间，从而提高用户体验。以下是CMS垃圾收集器的工作过程：1. 初始标记（Initial Mark）阶段：这是CMS的第一个阶段，也称为“STW（Stop-The-World）”阶段。目的：标记所有从GC Roots直接可达的对象。特点：这一步需要暂停所有用户线程（STW），但时间非常短。只扫描根对象（如全局变量、栈上的引用等），不扫描整个堆。2. 并发标记（Concurrent Mark）阶段：在初始标记之后，CMS进入并发标记阶段。目的：从初始标记的存活对象出发，遍历整个老年代，标记出所有存活的对象。特点：此阶段是并发执行的，即在应用程序运行的同时进行。不会暂停用户线程，因此对应用性能影响较小。由于是并发执行，可能会出现对象引用发生变化的情况（即“浮动垃圾”）。3. 重新标记（Remark）阶段：这是CMS的第二个STW阶段。**目的》，这篇文章主要讲到等等知识，如果你对文章相关的知识非常感兴趣或者正在自学，都可以关注我，我会持续更新相关文章！当然，有什么建议也欢迎在评论留言提出！一起学习！

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的前提下进行内存整理。

终于介绍完啦！小伙伴们，这篇关于《CMS垃圾回收器工作原理详解》的介绍应该让你收获多多了吧！欢迎大家收藏或分享给更多需要学习的朋友吧~golang学习网公众号也会发布文章相关知识，快来关注吧！