目录

前言

工作步骤

缺点

问题

---

前言

上一章节我们讲了串/并行GC，这一章节说下CMS GC。看前思考一个问题，并行GC与CMS GC的区别在哪里。

什么是CMS收集器

CMS(Concurrent Mark-Sweep)是以牺牲吞吐量为代价来获得最短回收停顿时间的垃圾回收器。对于要求服务器响应速度的应用上，这种垃圾回收器非常适合。

XX:+UseConcMarkSweepGC

其对年轻代采用并行 STW 方式的 mark-copy(标记-复制)算法，对老年代主要使用并发 mark-sweep(标记-清除)算法。

CMS GC 的设计目标是避免在老年代垃圾收集时出现长时间的卡顿，主要通过两种手段来达成此目标:

1.不对老年代进行整理，而是使用空闲列表 (freelists) 来管理内存空间的回收。

2.在 mark-and-sweep (标记-清除) 阶段的大部分工作和应用线程一起并发执行。

也就是说，在这些阶段并没有明显的应用线程暂停。但值得注意的是，它仍然和应用线程争抢CPU 。默认情况下，CMS 使用的并发线程数等于 CPU 核心数的 1/4。如果服务器是多核 CPU，并且主要调优目标是降低 GC 停顿导致的系统延迟，那么使用 CMS 是个很明智的选择。进行老年代的并发回收时，可能会伴随着多次年轻代的 minor GC

工作步骤（六个阶段）

1、4阶段是没有并发这俩字的是因为，这两个阶段都需要去做SWT。

• 阶段 1: Initial Mark (初始标记)

1. 初始标记阶段是CMS GC的第一阶段，主要目标是标记GC Roots能够直接关联（通过引用链）的对象。
2. 这个阶段需要“Stop the World”，暂停所有应用线程，只允许GC线程运行。
3. GC会从GC Roots出发（比如方法区类静态属性引用、虚拟机栈局部变量表引用等），对堆区对象进行追踪，标记被引用的对象。
4. 标记时，GC会借助卡表记录对象引用发生变化的区域，以提高旧时代的扫描效率。
5. 只有直接与GC Roots关联的对象才会被标记，降低初始标记的工作量。
6. 初始标记后，CMS进入下一个并发标记阶段，应用线程和GC线程并发执行。
7. 起始标记阶段的停止时间比较短，通常小于10ms。

综上，CMS GC的初始标记阶段主要进行GC Roots直接关联对象的标记，这是后续初始化标记的基础，同时记录卡表以优化效率。

总结：这个阶段伴随着 STW 暂停。初始标记的目标是标记所有的根对象，包括根对象直接引用的对象，以及年轻代指向老年代的对象(老年代单独回收) 。

• 阶段 2: Concurrent Mark (并发标记)

1. 并发标记是在初始标记完成后开始，应用线程和GC线程并发执行。
2. GC线程从原始标记的对象开始跟踪，标记这些对象直接及间接关联的对象。
3. 应用线程继续执行，当需要访问一个对象时，如果发现对象进行标记，则暂停应用线程，帮助进行标记。
4. 标记时仍需要协调对卡表的访问，CAS进行并发控制。
5. 情人节标记会重复多轮标记-Tracing process,知道对象所有的对象都被标记。
6. 为控制标记进程，会设置标记周期，如果标记时间超过一定阈值则停止应用线程进行完整GC。
7. ARM标记可与初始标记标记不同的对象，以完成对整个堆区的标记。
8. 并发标记阶段可以长期与应用线程任务，直到老年代使用达到一个阈值。

综上，允许CMS GC的并发标记GC与应用程序并发执行，可以将Stop The World时间最小化，降低应用程序延迟。它通过并发控制和多轮标记来逐步进行最后对象标记。

总结：在此阶段，CMS GC 遍历老年代，标记所有的存活对象，从前一阶段“Initial Mark”找到的根对象开始算起。“并发标记”阶段，就是与应用程序同时运行，不用暂停的阶段

• 阶段 3: Concurrent Preclean (并发预清理)

1. ARM预清理在ARM标记阶段结束后进行。
2. 其目标是商标在符号标记阶段因引用关系变化而从截至日期起不影响的对象。
3. CMS会重新扫描卡表（Card Table），精确在符号标记后被修改的区域。
4. 对于这些区域中的对象，CMS会检查它们的标记位是否仍为1。
5. 如果对象标记位为1但现在不可达，说明在符号标记后成为了浮动垃圾，CMS会重置其标记位为0。
6. 同时，应用线程继续并行运行。
7. 当预清理工作完成后，进入下一阶段停止时间会更短。
8. ARM预清理可以有效减少下个阶段的Stop The World停顿时间。

综上所述，CMS GC预清理阶段主要是初期阶段产生的浮动垃圾，减少下一阶段的工作量，从而达到大约停顿时间。

总结：此阶段同样是与应用线程并发执行的，不需要停止应用线程。 因为前一阶段[并发标记] 与程序并发运行，可能有一些引用关系已经发生了改变。如果在并发标记过程中引用关系发生了变化，JVM 会通过“Card (卡片)”的方式将发生了改变的区域标记为“脏”区，这就是所谓的 卡片标记 (Card Marking)

• 阶段 4: Final Remark (最终标记)

1. 最终标记需要“Stop the World”，暂停所有应用线程。
2. GC线程会进行全堆区的扫描，对标记位为0的对象进行重新标记。
3. 这一阶段的停顿时间会比初始标记停顿时间长一些。
4. 最终标记将标记各个阶段因引用关系变化而成为有意义的对象。
5. 它会修改符号标记和符号预清理阶段出现的不精确标记。
6. 通过最终标记，CMS可以精确识别出不影响物体。
7. 最终标记后，不影响对象的标记位仍为0，CMS就可以判断该对象为垃圾。
8. 然后CMS进入清理阶段回收这些垃圾对象。

综上，最终标记是停止所有应用线程进行的标记，它对并发标记做修改，准确描述标识所有不受影响的对象，为并发清理阶段做准备。

总结：最终标记阶段是此次 GC 事件中的第二次 (也是最后一次)STW停顿。本阶段的目标是完成老年代中所有存活对象的标记。因为之前的预清理阶段是并发执行的，有可能 GC 线程跟不上应用程序的修改速度。所以需要一次 STW 暂停来处理各种复杂的情况。

通常 CMS 会尝试在年轻代尽可能空的情况下执行 Final Remark阶段，以免连续触发多次 STW 事件。

• 阶段 5: Concurrent Sweep (并发清除 )

1. ARM清除是在最终标记结束后进行的。
2. 应用线程和GC线程都并发负载。
3. GC线程按区域(Region)进行分批回收。
4. 对于标记位为0的对象，意味着不影响，会被清除恢复。
5. 明确时会检查对象的年龄，如果年龄足够老可以放入老年代。
6. 被回收的区域会加入空闲列表，用于分配新对象。
7. 清除和应用线程一起执行，直到所有未触及对象清除完成。
8. 这避免了清除时的长时间停止。

综上，CMS GC的清理阶段可以避免清理所的停顿时间，同时恢复造成垃圾对象并腾出空间。

总结：此阶段与应用程序并发执行，不需要 STW 停顿。JVM 在此阶段删除不再使用的对象，并回收他们占用的内存空间

• 阶段 6: Concurrent Reset (并发重置）

1. 初始化是CMS GC收尾阶段后期进行的操作。
2. 它的目标是重置相关的数据结构，为下一个CMS周期做好准备。
3. GC线程会重置卡表，将记录的脏卡(Dirty Card)全部清空。
4. 同时重置CMSBitmap，以便重新记录对象标记信息。
5. 垃圾收集日志或统计信息在此阶段汇总和记录。
6. 重置时应用线程仍然可以并发执行。
7. 当重置完成后，CMS GC进入休眠，等待下一次触发条件出现。
8. 只有GC线程参与重置工作，应用线程不出行。

综上，CMS GC的重置阶段通过重置相关数据结构，为下一步CMS做好准备。

总结：此阶段与应用程序并发执行，重置 CMS 算法相关的内部数据，为下一次 GC 循环做准备。

占比

缺点

• CMS回收器采用的基础算法是Mark-Sweep。所有CMS不会整理、压缩堆空间。这样就会有一个问题：经过CMS收集的堆会产生空间碎片。 CMS不对堆空间整理压缩节约了垃圾回收的停顿时间，但也带来的堆空间的浪费。为了解决堆空间浪费问题，CMS回收器不再采用简单的指针指向一块可用堆空间来为下次对象分配使用。而是把一些未分配的空间汇总成一个列表，当JVM分配对象空间的时候，会搜索这个列表找到足够大的空间来hold住这个对象。
• 需要更多的CPU资源。从上面的图可以看到，为了让应用程序不停顿，CMS线程和应用程序线程并发执行，这样就需要有更多的CPU，单纯靠线程切换是不靠谱的。并且，重新标记阶段，为了保证STW快速完成，也要用到更多的甚至所有的CPU资源。当然，多核多CPU也是未来的趋势！
• CMS的另一个缺点是它需要更大的堆空间。因为CMS标记阶段应用程序的线程还是在执行的，那么就会有堆空间继续分配的情况，为了保证在CMS回 收完堆之前还有空间分配给正在运行的应用程序，必须预留一部分空间。也就是说，CMS不会在老年代满的时候才开始收集。相反，它会尝试更早的开始收集，已 避免上面提到的情况：在回收完成之前，堆没有足够空间分配！默认当老年代使用68%的时候，CMS就开始行动了。 – XX:CMSInitiatingOccupancyFraction =n 来设置这个阈值。

总得来说，CMS回收器减少了回收的停顿时间，但是降低了堆空间的利用率。

问题

初始化阶段中查找年轻代对年老代对象的引用，到底是否有使用RSet集合？

这个当时在望山搜了一些资料，发现有的说使用了有的说只在并发阶段使用了。本想去询问下客服，后来发现中国区客服貌似下线了。。。

最后终于发现在jdk1.8（实际是JDK 7 u4之后，为了方便记忆）引用了CMSBitmap。这个类似于RSet集合，但不是同一种数据格式。

1.我查看了OpenJDK1.8的hotspot源码在顶级类CMSCollector中,有以下注释：

// _initial_mark performs the initial marking of roots and uses
// the new _bitmap to mark live objects.
// _initial_mark执行根和使用的初始标记
//新的_bitmap来标记活动对象。

这说明了初始标记会使用CMSBitMap。

2.Oracle的官方文档中也提到:

The first phase of CMS is called initial mark. This phase only marks GC roots (stack variables, etc.) and objects directly reachable from them. Because this phase runs concurrently with the mutator threads, it must be conservative to avoid perturbing the running application. Thus, it uses card marks from the write barrier to identify object graphs that may have changed.
//翻译：CMS的第一阶段称为初始标记。这个阶段只标记GC根(堆栈变量等)和可直接访问的对象。因为这个阶段与mutator线程并发运行，所以它必须是保守的，以避免干扰正在运行的应用程序。因此，它使用写屏障中的卡片标记来识别可能已经更改的对象图。

这里说初始标记会使用write barrier记录的card mark信息,也就是CMSBitMap。

3.各种Books wie Tunning Java Performance也对此有描述综上所述我重新验证了JDK1.8 CMS GC 初始标记使用CMSBitMap的说法来自官方代码文档等多方佐证。请您放心,这一信息是可以靠谱的。如您还有任何疑问,欢迎随时提出,我会继续提供参考依据。

CMSBitmap和RSet集合的区别

1. 1.用途不同:

• CMS Bitmap 主要用于记录对象状态,用于判定对象是否可恢复。
• RSet主要记录对象之间的引用关系，用于优化快速对象。

1. 2.实现不同:

• CMS Bitmap通常使用位图来记录对象标记信息。
• RSet使用Card Table或独立的位图实现。

1. 3.使用场景不同：

• CMS Bitmap用于CMS等垃圾收集器中，与收集器紧密相关。
• RSet更通用、跨代引用和间歇恢复都能禁用。

1. 4.生命周期不同：

• CMS位图每次GC会重置。
• RSet的内容会增量更新，不会重置。

1. 5.内存占用费用:

• CMS Bitmap按对象数量分配，占用内存较小。
• RSet 需要记录详细引用，占用内存相对增加。

1. 6.数据准确度不同:

• CMS Bitmap记录单个对象状态，精确度高。
• RSet基于Card来记录引用变化范围，精确度较低。

官方参考文档：

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

课程链接：阿里云盘分享

今天就到这里吧，感觉有用的小伙伴可以点个赞，你的支持就是我更新的最大动力！