CMS 垃圾收集器详解（工作流程 + 优缺点 + 面试总结）

在 JVM 垃圾回收器中，CMS（Concurrent Mark Sweep）曾经是非常重要的一款收集器，尤其是在对低延迟要求较高的系统中被广泛使用。

虽然在新版本 JDK 中已经被淘汰，但它依然是面试中的高频考点。

本文将从工作流程、优缺点以及使用场景三个方面，系统讲清 CMS。

---

一、什么是 CMS？

CMS 全称：

Concurrent Mark Sweep（并发标记-清除）

---

👉 核心特点：

以“最小停顿时间”为目标的垃圾收集器

---

👉 基本信息：

• 使用算法：标记-清除（Mark-Sweep）
• 作用区域：老年代
• 最大特点：并发执行（与用户线程同时运行）

---

二、CMS 工作流程（重点）

CMS 的执行流程分为四个阶段：

---

1️⃣ 初始标记（Initial Mark）

标记 GC Roots 直接关联的对象

---

特点：

• 需要 Stop-The-World（STW）
• 执行速度快（只标记一层）

---

---

2️⃣ 并发标记（Concurrent Mark）

从 GC Roots 出发，遍历整个对象图

---

特点：

• 与用户线程并发执行
• 耗时最长
• 不会暂停应用

---

---

3️⃣ 重新标记（Remark）

修正并发标记期间发生变化的对象引用

---

原因：

• 并发阶段用户线程仍在运行
• 引用关系可能变化

---

特点：

• 需要 STW
• 时间比初始标记稍长

---

---

4️⃣ 并发清除（Concurrent Sweep）

清理未被标记的对象（垃圾）

---

特点：

• 与用户线程并发执行
• 不需要移动对象

---

---

三、流程总结

初始标记（STW）
→ 并发标记
→ 重新标记（STW）
→ 并发清除

---

四、CMS 的优点

---

✅ 1. 低停顿（最大优势）

大部分时间与用户线程并发执行

---

👉 适用于：

• Web 服务
• 实时系统
• 对响应时间敏感的应用

---

---

✅ 2. 响应速度快

• 停顿时间短
• 用户体验更好

---

五、CMS 的缺点（重点）

---

❌ 1. 内存碎片问题

使用标记-清除算法 → 不整理内存

---

👉 结果：

• 空间不连续
• 大对象分配困难

---

---

❌ 2. CPU 资源敏感

GC 线程和业务线程竞争 CPU

---

👉 影响：

• 系统吞吐量下降

---

---

❌ 3. 浮动垃圾（Floating Garbage）

并发清理期间产生的新垃圾无法本次回收

---

👉 结果：

• 需要预留空间
• 否则容易触发 Full GC

---

---

❌ 4. 容易触发 Full GC（最严重）

当出现：

内存不足 或 碎片严重

---

👉 会退化为：

Serial Old（单线程 Full GC）

---

👉 问题：

• 停顿时间非常长 ❗

---

---

❌ 5. 已被淘汰

JDK 9 标记废弃
JDK 14 移除

---

👉 原因：

被 G1 收集器替代

---

六、适用场景

---

✔ 适合：

对延迟敏感的系统（低停顿优先）

---

❌ 不适合：

• CPU 资源紧张
• 内存较小
• 对吞吐量要求高的系统

---

七、面试高频总结

---

✔ CMS 工作流程？

初始标记 → 并发标记 → 重新标记 → 并发清除

---

✔ CMS 优点？

低停顿、并发执行

---

✔ CMS 缺点？

1. 内存碎片
2. CPU 开销大
3. 浮动垃圾
4. 易 Full GC

---

✔ 为什么被淘汰？

无法解决碎片问题，稳定性差，被 G1 替代

---

八、终极总结

CMS 的本质：
用“并发”换“低停顿”

---

再补一句核心理解：

牺牲吞吐量和空间连续性，换取更好的响应时间

---

九、结语

CMS 是 JVM 垃圾回收历史中的重要一环：

• 带来了“低停顿”的理念
• 但也暴露了并发回收的复杂性