JVM垃圾回收器CMS与G1

本文目录导读：

1. 核心区别一览
2. CMS详解（已淘汰，但思想重要）
3. G1详解（现代默认）
4. 总结对比：何时用哪个？

这是一个非常经典且重要的JVM面试题，CMS和G1都是低延迟垃圾回收器,但它们的核心设计思想和适用场景有很大不同。

我将从设计目标、工作步骤、核心特点、优缺点、适用场景几个维度进行对比分析。

核心区别一览

CMS详解（已淘汰，但思想重要）

工作流程（4步）

• 初始标记（STW，很短）：标记GC Roots直接关联的对象,以及年轻代指向老年代的引用。
• 并发标记（无STW）：从GC Roots开始遍历整个老年代，标记所有存活对象。耗时最长,与应用线程并发执行。
• 重新标记（STW，比初始标记长）：修正并发标记期间因用户线程继续运行而产生变动的对象标记记录。
• 并发清除（无STW）：清除未被标记的对象,回收内存。

优点

• 并发标记 & 并发清除：真正做到了低延迟,停顿时间极短。
• 对老年代回收效率高（在碎片不严重时）。

痛点

• 内存碎片：标记-清除算法必然导致碎片，当碎片太多，无法为大对象分配连续空间时，触发Full GC（Serial Old，单线程，非常慢）。
• CPU敏感：并发阶段占用CPU资源,在CPU核心少的环境下会拖慢应用。
• 浮动垃圾：并发标记阶段产生的垃圾无法在本次回收，只能等下次，因此需要预留空间给并发标记线程执行,不能等到堆满才触发。
• 并发模式失败（Concurrent Mode Failure）：如果并发标记期间，预留空间不够，触发Full GC。

G1详解（现代默认）

G1的核心思想是 “把堆分成多个独立的小块（Region），每次只回收收益最高（垃圾最多）的那一批”。

堆内存结构（Region）

• Region：堆被分成约2048个大小相等（1MB-32MB）的Region。
• Eden / Survivor / Old / Humongous（巨型对象）：这些逻辑分代对应不同Region，但Region是动态分配的，某个Region之前是老年代,回收后可变为年轻代。
• Humongous Region：专门存放大小超过Region 50%的对象,防止大对象在正常Region间移动。

工作流程（5步）

1. 初始标记（STW，很短）：标记GC Roots直接关联的对象。同时完成了Young GC（年轻代回收）。
2. 并发标记（无STW）：从GC Roots开始遍历整个堆（包括老年代）,标记存活对象。
3. 最终标记（STW，略长）：处理并发标记短暂遗漏的引用变更（SATB，Snapshot-At-The-Beginning算法）。
4. 筛选回收（STW，可预测）：核心步骤，G1会统计所有Region的回收收益（回收垃圾量 / 回收耗时），然后选择一批收益最高的Region进行回收，回收时使用复制算法，将存活对象压缩到另一个Region,彻底消除碎片。
5. 可选：并发清除（无STW）：回收完全没对象的Region。

关键特性

• 停顿时间模型：通过 -XX:MaxGCPauseMillis（默认200ms）指定目标停顿时间，G1会动态调整年轻代大小、Region回收数量等来尽量满足此目标。
• 无碎片：因为回收时用了复制/整理算法。
• 可预测停顿：通过筛选回收,每次STW时间可控。

优点

• 低延迟：停顿时间可控，且通常远低于CMS的Full GC风险。
• 高吞吐量：在停顿时间目标下,尽量多回收内存。
• 自动调优：不需要额外设置太多参数（如CMS的-XX:CMSInitiatingOccupancyFraction）。

缺点

• 内存占用略高：需要额外的Remembered Set（记录跨Region引用）数据结构，约5%-10%的堆内存。
• 响应时间不如ZGC/Shenandoah：虽然优于CMS，但在极低延迟（<10ms）场景下不如ZGC。

总结对比：何时用哪个？

• CMS（历史选择）：

  • 适合JDK 8及以前，对停顿时间敏感，且堆内存不大（<4GB~6GB） 的场景。
  • 注意：如果堆很大（>6GB），CMS的碎片和Full GC风险会指数级上升。

• G1（现代选择）：

  • JDK 9及以上的默认选择。
  • 适合堆内存较大（>6GB），且需要可预测、较低停顿时间（如100ms-500ms） 的场景。
  • 适合需要消除内存碎片，避免长时间Full GC的应用。

• 超越G1：

  • 如果延迟要求极高（<10ms），或者堆内存极大（>100GB），应优先考虑 ZGC（JDK 11+） 或 Shenandoah（JDK 12+）。

CMS是追求低延迟的“先驱”，但受困于内存碎片和Full GC风险；G1是更均衡的“后继者”，通过分区回收和停顿预测，在延迟与吞吐量之间取得了更好的平衡，并已成为现代Java应用的主流选择。