垃圾收集器全览：Serial → Parallel → CMS → G1 → ZGC

垃圾收集器是 JVM 面试中区分度极高的话题。初级工程师知道"有 GC"，中级工程师知道"G1 是默认"，而高级工程师能讲清楚为什么会有五代收集器，每一代在吞吐量、延迟、内存 footprint 三者之间做了怎样的取舍。

JDK 的垃圾收集器演进史就是一部"如何在停顿时间与吞吐量之间寻找最优解"的工程史：

Serial GC 是 JVM 最古老的垃圾收集器，也是最简单的一个。它的核心思想只有一句话：用一个线程来完成所有垃圾回收工作，回收期间暂停所有用户线程（Stop-The-World）。

工作流程

Serial GC 对新生代和老年代分别使用不同的算法：

• 新生代（Young Gen）：使用 复制算法（Copying）。将 Eden 和 From Survivor 中的存活对象复制到 To Survivor，然后清空 Eden 和 From。这个过程称为 Minor GC。
• 老年代（Old Gen）：使用 标记-整理算法（Mark-Compact）。先标记所有存活对象，然后将它们向一端移动压缩，最后清理边界之外的空间。这个过程称为 Major GC / Full GC。

# 客户端模式（Client VM）默认启用
java -XX:+UseSerialGC -jar app.jar

# 典型适用场景
# - 堆大小 < 100MB 的小型应用
# - 单核 CPU 环境（如容器内 cpu=1）
# - GraalVM Native Image 默认 GC

Serial GC 的优劣势

Parallel GC（也叫 Throughput Collector）是 JDK 8 的默认垃圾收集器。它的设计目标非常明确：最大化应用程序的吞吐量。做法也很直接——把 Serial GC 的单线程回收改成多线程并行回收。

新生代：Parallel Scavenge（并行复制）

新生代使用 Mark-Copy 算法，多线程并行完成：

1. 多线程并行扫描根集合（GC Roots），标记 Eden 和 From Survivor 中的存活对象
2. 多线程并行将存活对象复制到 To Survivor
3. 清空 Eden 和 From Survivor

Parallel Scavenge 收集器有一个独特特性：它关注的是吞吐量而非停顿时间，因此提供了 -XX:MaxGCPauseMillis（最大停顿目标）和 -XX:GCTimeRatio（GC 时间占比目标）两个自适应调节参数。

老年代：Parallel Old（并行标记-整理）

老年代使用 Parallel Mark-Compact：多线程并行标记存活对象，然后多线程并行压缩整理。这比 CMS 的标记-清除算法有更好的空间利用率（无碎片），但停顿时间更长。

# 启用 Parallel GC（JDK 8 默认）
java -XX:+UseParallelGC -XX:+UseParallelOldGC \
     -XX:ParallelGCThreads=8          # GC 线程数，默认=CPU 核心数
     -XX:MaxGCPauseMillis=200        # 目标最大停顿时间
     -XX:GCTimeRatio=19              # 目标 GC 时间占比 1/(1+19) = 5%
     -jar app.jar

CMS（Concurrent Mark-Sweep）是 JDK 1.5 引入的低延迟收集器，在 JDK 5~8 时代是 Web 应用的首选。它的设计目标与 Parallel GC 完全相反：最小化停顿时间。CMS 通过将大部分回收工作与用户线程并发执行来实现这一目标。

CMS 的四个阶段

CMS 的老年代回收分为四个阶段，其中两个需要 STW，两个与用户线程并发：

CMS 的三大问题

问题一：浮动垃圾（Floating Garbage）

在并发清除阶段，用户线程仍在运行，会产生新的垃圾。这些垃圾只能在下一次 GC 时才能被回收。这意味着 CMS 不能等到堆快满了才启动 GC，需要提前触发——通常当老年代使用率达到 68%（-XX:CMSInitiatingOccupancyFraction）时就开始回收。

问题二：并发模式失败（Concurrent Mode Failure）

如果 CMS 回收的速度赶不上对象分配的速度，老年代空间耗尽，CMS 就会退化为一次 Full GC（Serial Old 单线程标记-整理），停顿时间暴涨到秒级。这是 CMS 最让人头疼的问题。

问题三：内存碎片

CMS 使用标记-清除算法，不会压缩整理老年代，因此会产生大量内存碎片。碎片化严重时，即使总空闲内存足够，也可能因为找不到连续空间来分配大对象而触发 Full GC。

# JDK 8 中启用 CMS
java -XX:+UseConcMarkSweepGC \
     -XX:CMSInitiatingOccupancyFraction=68  # 老年代占用 68% 时触发
     -XX:+UseCMSInitiatingOccupancyOnly      # 只在达到阈值时触发
     -XX:+CMSScavengeBeforeRemark            # Remark 前先做一次 Minor GC
     -jar app.jar

# JDK 9: -XX:+UseConcMarkSweepGC 产生警告
# JDK 14: 彻底移除 CMS，使用该参数会报错

G1（Garbage First）是 JDK 9 以来的默认垃圾收集器。它从架构层面颠覆了前面几代收集器的设计思路：不再将堆划分为固定的新生代和老年代，而是将整个堆划分为大小相等的 Region。每个 Region 可以动态扮演 Eden、Survivor、Old 或 Humongous 角色。

Region 架构

G1 将堆划分为约 2048 个大小相等的 Region，每个 Region 大小在 1MB~32MB 之间（必须是 2 的幂次方），由堆大小自动决定：

G1 的回收过程

G1 的回收分为两种类型：

Young GC：回收所有 Eden 和 Survivor Region。使用多线程并行复制存活对象到新的 Region（本质上是并行复制算法）。

Mixed GC：在 Young GC 的基础上，额外选择部分老年代 Region 一起回收。G1 通过并发标记周期来确定哪些老年代 Region 的垃圾比例最高（Garbage First），然后选择收益最高的 Region 进行回收。

并发标记周期

G1 的并发标记与 CMS 类似，但更简洁，因为 G1 使用了 Snapshot-At-The-Beginning（SATB） 算法：

1. 初始标记（STW）：标记 GC Roots 直接引用的对象，搭载在 Young GC 的 STW 阶段
2. 并发标记：与用户线程并发遍历对象图
3. 最终标记（STW）：处理 SATB 队列中的引用变更记录
4. 筛选回收（STW）：计算每个 Region 的回收价值（垃圾比例），选择性价比最高的 Region 组成 Collection Set

Remembered Set（RSet）

因为 Region 的角色是动态的，G1 无法像分代收集器那样只扫描新生代。为了解决跨 Region 引用的问题，每个 Region 都维护一个 RSet，记录"谁引用了我"。这样在 Young GC 时，只需扫描年轻代 Region 的 RSet 就能找到所有引用关系，而不需要扫描整个老年代。

RSet 的代价：每个 Region 的 RSet 通常占用 Region 大小的 5%~20%，这是 G1 内存开销比 Parallel GC 更高的主要原因之一。

java -XX:+UseG1GC \
     -XX:MaxGCPauseMillis=200          # 目标最大停顿时间（默认 200ms）
     -XX:G1HeapRegionSize=4m          # Region 大小（1m/2m/4m/.../32m）
     -XX:InitiatingHeapOccupancyPercent=45 # 触发并发标记的堆占用率
     -XX:G1NewSizePercent=20          # 新生代最小占比（默认 5%）
     -XX:G1MaxNewSizePercent=60       # 新生代最大占比（默认 60%）
     -XX:ConcGCThreads=2              # 并发标记线程数
     -XX:G1ReservePercent=10          # 保留空间防 evacuation failure
     -jar app.jar

Evacuation Failure（疏散失败）

类似 CMS 的并发模式失败，G1 在 Mixed GC 期间如果没有足够的空闲 Region 来存放存活对象，就会触发 Evacuation Failure，退化为一次 Full GC（单线程标记-整理，JDK 10 后改为多线程）。这是 G1 调优中需要极力避免的情况。

ZGC（Z Garbage Collector）是 JDK 11 引入的实验性收集器，JDK 15 正式生产可用。它的目标极其大胆：停顿时间不超过 1 毫秒，且不随堆大小增长。无论堆是 8GB 还是 16TB，停顿时间都保持在亚毫秒级别。

核心机制一：染色指针（Colored Pointers）

ZGC 最核心的创新是染色指针——利用 64 位指针中的空闲位来存储 GC 元数据。在 64 位系统中，虚拟地址空间远大于实际物理内存，指针的高位通常有多余的 bit。ZGC 利用这些 bit 来存储四个标记：

核心机制二：读屏障（Load Barrier）

当应用线程通过指针读取对象引用时，ZGC 会在读取前插入一段读屏障代码。读屏障会检查指针的染色位：

• 如果指针的 Remapped 位被设置，说明对象已经被 GC 转移到了新地址，读屏障会自动修正指针指向新地址
• 这样就不需要像 G1 那样在 STW 阶段批量修正所有引用——修正工作被分散到了每次指针读取时

核心机制三：并发转移（Concurrent Relocation）

ZGC 将 G1 中必须 STW 的 Evacuation（转移存活对象）阶段也变成了并发的：

1. GC 线程并发将存活对象从旧 Region 复制到新 Region
2. 旧地址的指针被标记为 Remapped（染色位）
3. 应用线程下次通过读屏障访问该指针时，自动修正为新地址
4. 当所有旧指针都被修正后，旧 Region 可以被安全回收

ZGC 的执行流程

注意：所有 STW 阶段都是亚毫秒级的，最长的 Pause Mark End 通常也不超过 1ms。

# JDK 11（实验性）
java -XX:+UnlockExperimentalVMOptions -XX:+UseZGC -jar app.jar

# JDK 15+（生产可用，无需 UnlockExperimental）
java -XX:+UseZGC -jar app.jar

# JDK 17+ 启用分代 ZGC（进一步提升吞吐量）
java -XX:+UseZGC -XX:+ZGenerational -jar app.jar

# ZGC 默认最大堆 16TB，适用于超大堆场景

ZGC 的取舍

GC 演进时间线

选择决策树

/*
 * 第一步：你的堆有多大？
 */
if (heapSize < 100MB && cpuCores == 1) {
    return Serial;           // 小堆单核，简单就是美
}

if (heapSize < 4GB && 吞吐量优先) {
    return Parallel;         // 批处理、后台任务
}

if (heapSize < 64GB && 通用场景) {
    return G1;               // JDK 9+ 默认，大多数场景的最优选
}

if (延迟敏感 || heapSize > 16GB || P99要求 < 10ms) {
    return ZGC;              // 超低延迟，JDK 15+
}

// 默认：用 G1，别折腾
return G1;

生产环境 GC 监控指标

# JDK 9+ 统一日志
java -Xlog:gc*,gc+heap=debug:file=gc-%t.log:time,uptime,level,tags:filecount=5,filesize=10M

# JDK 8 传统参数
java -XX:+PrintGCDetails -XX:+PrintGCDateStamps \
     -Xloggc:/var/log/gc-%t.log \
     -XX:+UseGCLogFileRotation \
     -XX:NumberOfGCLogFiles=5 \
     -XX:GCLogFileSize=10M