JVM垃圾回收：ZGC与Shenandoah 系统性知识体系（2026超高频）

一、整体定位与发展历程

1.1 低延迟垃圾收集器诞生背景

• 痛点：传统收集器（Serial、Parallel、CMS、G1）在大堆（100GB+）场景下停顿时间过长（G1通常在100ms以上）
• 目标：将GC停顿时间控制在亚毫秒级（<10ms），且停顿时间不随堆大小增长而增加
• 核心设计理念：并发执行所有耗时操作，仅在必要时进行极短暂的STW（Stop-The-World）

1.2 发展历程对比

二、ZGC核心原理与关键技术

2.1 核心设计思想

• 基于Region的内存布局：将堆划分为多个大小相等的Region（2MB/32MB/256MB，根据堆大小自动选择）
• 着色指针（Colored Pointer）：利用64位指针的高几位存储对象的元数据信息
• 读屏障（Load Barrier）：在读取对象引用时执行的一小段代码，用于处理并发转移
• 多映射内存（Multi-Mapping）：将同一块物理内存映射到多个虚拟地址空间

2.2 着色指针技术详解

ZGC利用64位指针的第42-45位存储4个标记位：

• Marked0（M0）：第42位，标记阶段0的存活对象
• Marked1（M1）：第43位，标记阶段1的存活对象
• Remapped（R）：第44位，对象已被转移到新地址
• Finalizable（F）：第45位，对象有finalize方法需要执行

优势：

• 无需在对象头中存储标记位，节省内存
• 标记和转移操作可以完全并发进行
• 转移完成后无需更新所有引用，通过读屏障自动修正

2.3 读屏障技术

当应用线程读取一个对象引用时，ZGC会自动插入读屏障：

// 伪代码
Object load(Object* ref) {
    if (ref has Remapped bit set) {
        return ref;
    }
    // 尝试将引用更新到新地址
    Object* new_ref = get_forwarded_address(ref);
    // CAS更新引用
    if (CAS(ref, new_ref)) {
        return new_ref;
    }
    // 其他线程已经更新，重新读取
    return load(ref);
}

关键特性：

• 仅在读操作时触发，写操作无需屏障
• 开销极低（现代CPU可预测分支）
• 实现了并发转移，转移过程中应用线程可以继续运行

2.4 ZGC垃圾回收周期

ZGC的回收周期分为4个主要阶段，其中只有两个极短的STW阶段：

1. 初始标记（STW）：标记GC Roots直接引用的对象，停顿时间<1ms
2. 并发标记：遍历对象图，标记所有存活对象，与应用线程并发执行
3. 最终标记（STW）：处理并发标记阶段的引用变化，停顿时间<1ms
4. 并发转移：将存活对象复制到新的Region，同时通过读屏障修正引用
5. 并发重映射：修正所有未被读屏障处理的引用（可与下一次标记合并）

三、Shenandoah核心原理与关键技术

3.1 核心设计思想

• 基于Region的内存布局：与ZGC类似，划分为多个大小相等的Region
• Brooks指针（Brooks Pointer）：每个对象头中包含一个指向自身的转发指针
• 读写屏障：在读写对象引用时执行屏障操作
• 连接矩阵（Connection Matrix）：记录Region之间的引用关系，优化跨代引用处理

3.2 Brooks指针技术

每个对象头中额外存储一个转发指针，初始时指向对象自身：

// 对象头结构
struct ObjectHeader {
    mark_word;      // 标记字
    klass_ptr;      // 类指针
    brooks_ptr;     // 转发指针（Shenandoah特有）
};

工作原理：

• 当对象被转移时，将原对象的Brooks指针指向新对象
• 所有对原对象的访问都会通过Brooks指针重定向到新对象
• 转移完成后，后台线程逐步更新所有引用

3.3 Shenandoah垃圾回收周期

Shenandoah的回收周期比ZGC更复杂，包含9个阶段：

1. 初始标记（STW）：标记GC Roots直接引用的对象
2. 并发标记：遍历对象图，标记所有存活对象
3. 最终标记（STW）：处理并发标记阶段的引用变化
4. 并发清理：回收没有存活对象的Region
5. 并发准备转移：选择需要转移的Region集合
6. 初始转移（STW）：将GC Roots引用更新到新地址
7. 并发转移：将存活对象复制到新的Region
8. 最终更新引用（STW）：更新所有剩余的引用
9. 并发清理：回收转移完成后的旧Region

四、低延迟特性深度解析

4.1 低延迟的核心保障

• 全并发执行：所有耗时操作（标记、转移、清理）均与应用线程并发执行
• 停顿时间与堆大小无关：停顿时间仅与GC Roots数量和引用变化率有关
• 增量式处理：将大任务拆分为多个小任务，避免长时间STW
• 预测性调度：根据应用负载动态调整GC线程数量和执行时间

4.2 典型停顿时间对比

4.3 吞吐量与延迟的权衡

• ZGC/Shenandoah vs G1：吞吐量略低（约5-15%），但延迟降低一个数量级
• ZGC vs Shenandoah：ZGC的平均停顿时间更短，Shenandoah的吞吐量略高
• 适用场景：对延迟敏感的应用（微服务、实时系统、金融交易）优先选择ZGC/Shenandoah

五、JDK21分代ZGC优化（2026超高频考点）

5.1 分代ZGC诞生背景

• 不分代ZGC的痛点：
  1. 每次回收都需要扫描整个堆，大堆场景下CPU开销高
  2. 无法利用"弱分代假说"，导致不必要的对象复制
  3. 内存碎片问题仍然存在，需要定期执行Full GC
• 分代设计的优势：
  1. 新生代对象存活率低，回收效率高
  2. 老年代对象存活率高，回收频率低
  3. 整体吞吐量提升，CPU开销降低

5.2 分代ZGC内存布局

分代ZGC将堆划分为两个代：

• 新生代（Young Generation）：
  • 进一步划分为Eden区和Survivor区
  • 采用复制算法进行回收
  • 回收频率高，每次回收只处理新生代
• 老年代（Old Generation）：
  • 采用标记-整理算法进行回收
  • 回收频率低，只有在老年代满时才触发
  • 支持并发转移和并发标记

5.3 分代ZGC关键优化点

1. 双标记位循环使用：

   • 新生代和老年代使用不同的标记位（M0/M1）
   • 避免了代之间的标记干扰
   • 实现了代独立回收

2. 跨代引用处理：

   • 使用卡表（Card Table）记录老年代对新生代的引用
   • 新生代回收时只需扫描卡表中的脏卡，无需扫描整个老年代
   • 卡表更新通过写屏障实现，开销极低

3. 晋升机制优化：

   • 对象在Survivor区经历一定次数的回收后晋升到老年代
   • 大对象直接分配在老年代
   • 支持动态调整晋升阈值

4. GC触发条件优化：

   • 新生代：Eden区满时触发
   • 老年代：老年代使用率达到阈值时触发
   • 支持自适应调整阈值，根据应用负载动态优化

5.4 分代ZGC性能提升

• 吞吐量提升：相比不分代ZGC，吞吐量提升20-50%
• CPU开销降低：新生代回收只扫描小部分堆，CPU使用率降低
• 内存利用率提高：分代设计减少了内存碎片
• 停顿时间保持：仍然保持亚毫秒级停顿，最大停顿时间<5ms

六、ZGC vs Shenandoah 深度对比

6.1 核心技术对比

6.2 性能对比

6.3 适用场景

• ZGC优先选择：

  • 对延迟要求极高的应用（<10ms）
  • 大堆场景（100GB+）
  • 微服务、实时系统、金融交易
  • JDK21及以上版本

• Shenandoah优先选择：

  • 对吞吐量有一定要求的低延迟应用
  • 需要全平台支持的场景
  • JDK17及以上版本

• G1优先选择：

  • 对吞吐量要求高，延迟要求一般的应用
  • 堆大小较小（<32GB）的场景
  • JDK8及以下版本

七、调优指南与最佳实践

7.1 ZGC调优参数

# 启用ZGC
-XX:+UseZGC

# 启用分代ZGC（JDK21+，默认开启）
-XX:+ZGenerational

# 设置堆大小
-Xms16g -Xmx16g

# 设置GC线程数（默认等于CPU核心数）
-XX:ConcGCThreads=4

# 设置最大停顿时间目标（默认200ms，ZGC会尽力满足）
-XX:MaxGCPauseMillis=5

# 启用大页支持（提升性能）
-XX:+UseLargePages

7.2 Shenandoah调优参数

# 启用Shenandoah
-XX:+UseShenandoahGC

# 启用分代Shenandoah（JDK21+）
-XX:+ShenandoahGenerational

# 设置GC线程数
-XX:ConcGCThreads=4

# 设置最大停顿时间目标
-XX:MaxGCPauseMillis=10

7.3 最佳实践

1. 堆大小设置：建议设置为物理内存的50-70%，避免堆过小导致频繁GC
2. GC线程数：默认值通常足够，不要设置过多，避免与应用线程竞争CPU
3. 大页支持：强烈建议启用大页，可显著提升性能
4. JDK版本：尽可能使用最新的JDK版本（JDK21+），分代ZGC性能提升明显
5. 监控指标：重点关注GC停顿时间、GC频率、吞吐量和CPU使用率

八、2026面试高频考点

8.1 基础概念题

1. ZGC和Shenandoah的核心设计思想是什么？
2. 着色指针和Brooks指针的区别是什么？
3. 读屏障和写屏障在ZGC和Shenandoah中的作用是什么？
4. 为什么ZGC的停顿时间与堆大小无关？

8.2 原理深度题

1. 详细描述ZGC的垃圾回收周期，指出哪些阶段是STW的？
2. 分代ZGC解决了不分代ZGC的哪些问题？
3. 分代ZGC的内存布局是怎样的？跨代引用如何处理？
4. Shenandoah的连接矩阵有什么作用？

8.3 对比分析题

1. ZGC vs Shenandoah vs G1的优缺点对比？
2. 分代ZGC相比不分代ZGC有哪些性能提升？
3. 什么场景下应该选择ZGC，什么场景下应该选择Shenandoah？

8.4 调优实践题

1. 如何开启分代ZGC？有哪些关键调优参数？
2. 如果ZGC的停顿时间过长，应该如何排查和调优？
3. 大堆场景下使用ZGC有哪些注意事项？

九、未来发展趋势

• 进一步降低停顿时间：目标是实现亚微秒级停顿
• 自动调优增强：根据应用负载自动调整GC参数
• 硬件加速：利用现代CPU的特性（如AVX-512）加速GC操作
• 统一垃圾回收框架：JDK正在逐步统一不同收集器的代码框架
• 弹性堆大小：支持根据应用负载动态调整堆大小

ZGC与Shenandoah 面试背诵问答卡片（2026超高频）

一、基础概念题（必背）

1. 问题：ZGC和Shenandoah诞生的核心背景与设计目标是什么？
   答案：诞生背景是传统收集器（G1等）在100GB+大堆场景下停顿时间过长（>100ms）且随堆增大而增加。核心设计目标是将GC停顿时间控制在亚毫秒级（<10ms），且停顿时间与堆大小无关，通过并发执行所有耗时操作实现。

2. 问题：ZGC的三大核心技术是什么？
   答案：① 基于Region的内存布局（2MB/32MB/256MB自动选择）；② 着色指针（利用64位指针高位存储对象元数据）；③ 读屏障（仅在读操作时触发，实现并发转移）。

3. 问题：Shenandoah的三大核心技术是什么？
   答案：① 基于Region的内存布局；② Brooks指针（对象头中存储转发指针）；③ 读写屏障（读写操作均触发，配合Brooks指针实现重定向）。

4. 问题：为什么ZGC和Shenandoah的停顿时间与堆大小无关？
   答案：它们的STW阶段仅处理GC Roots和引用变化，不扫描整个堆。所有耗时的标记、转移、清理操作均与应用线程并发执行，停顿时间只与GC Roots数量和引用变化率有关，与堆总大小无关。

二、核心原理题（高频）

1. 问题：详细解释ZGC的着色指针技术，四个标记位分别是什么？
   答案：ZGC利用64位指针的第42-45位存储4个标记位：

   • M0（第42位）：标记阶段0的存活对象
   • M1（第43位）：标记阶段1的存活对象
   • Remapped（第44位）：对象已被转移到新地址
   • Finalizable（第45位）：对象有finalize方法需要执行
     优势：无需对象头存储标记位，标记和转移可完全并发，转移后无需立即更新所有引用。

2. 问题：ZGC的读屏障是如何工作的？
   答案：当应用线程读取对象引用时，自动插入读屏障：

   1. 检查引用的Remapped位是否已设置，已设置则直接返回
   2. 未设置则获取对象的转发地址
   3. 通过CAS原子更新引用到新地址
   4. 返回新地址的对象
      特点：仅读操作触发，开销极低，实现了无停顿并发转移。

3. 问题：ZGC的垃圾回收周期包含哪些阶段？哪些是STW的？
   答案：共5个阶段，仅2个极短STW阶段：

   1. 初始标记（STW，<1ms）：标记GC Roots直接引用
   2. 并发标记：遍历对象图标记所有存活对象
   3. 最终标记（STW，<1ms）：处理并发标记期间的引用变化
   4. 并发转移：将存活对象复制到新Region
   5. 并发重映射：修正剩余未更新的引用（可与下一次标记合并）

4. 问题：Shenandoah的Brooks指针是如何工作的？
   答案：每个对象头额外存储一个转发指针，初始指向自身。当对象被转移时，将原对象的Brooks指针指向新对象。所有对原对象的访问都会通过Brooks指针自动重定向到新对象，转移完成后后台线程逐步更新所有引用。

5. 问题：Shenandoah的垃圾回收周期包含哪些关键STW阶段？
   答案：共4个STW阶段，均为亚毫秒级：

   1. 初始标记：标记GC Roots直接引用
   2. 最终标记：处理并发标记的引用变化
   3. 初始转移：更新GC Roots引用到新地址
   4. 最终更新引用：更新所有剩余的引用

三、JDK21分代ZGC专题（2026超高频）

1. 问题：不分代ZGC存在哪些核心痛点？分代ZGC解决了什么问题？
   答案：不分代ZGC痛点：

   • 每次回收扫描整个堆，大堆CPU开销高
   • 无法利用弱分代假说，大量短生命周期对象被重复复制
   • 内存碎片问题仍存在，需定期Full GC
     分代ZGC解决：吞吐量提升20-50%，CPU开销降低，内存利用率提高，同时保持亚毫秒级停顿。

2. 问题：分代ZGC的内存布局是怎样的？
   答案：将堆划分为两个独立代：

   • 新生代：进一步分为Eden区和Survivor区，采用复制算法，回收频率高
   • 老年代：采用标记-整理算法，回收频率低，仅在老年代满时触发
     两代使用不同的标记位（M0/M1）循环，实现代独立回收。

3. 问题：分代ZGC如何处理跨代引用？
   答案：使用卡表（Card Table）记录老年代对新生代的引用。老年代被划分为512字节的卡，当老年代对象引用新生代对象时，对应的卡被标记为脏卡。新生代回收时只需扫描脏卡，无需扫描整个老年代，卡表更新通过写屏障实现。

4. 问题：分代ZGC相比不分代ZGC有哪些关键性能提升？
   答案：

   • 吞吐量提升20-50%（核心提升）
   • CPU使用率降低30%左右（新生代回收仅扫描小部分堆）
   • 内存碎片显著减少，内存利用率提高
   • 最大停顿时间从<10ms进一步降低到<5ms
   • 大幅降低了大堆场景下的Full GC概率

5. 问题：JDK21中分代ZGC是默认开启的吗？如何手动开启/关闭？
   答案：JDK21及以上版本中，分代ZGC是默认开启的。手动开启：-XX:+ZGenerational；手动关闭（使用不分代ZGC）：-XX:-ZGenerational。

四、对比分析题（高频）

1. 问题：ZGC和Shenandoah的核心技术区别是什么？
   答案：

1. 问题：ZGC、Shenandoah和G1的适用场景分别是什么？
   答案：

   • ZGC：对延迟要求极高（<10ms）的大堆（100GB+）场景，如金融交易、实时系统、微服务，推荐JDK21+
   • Shenandoah：对吞吐量有一定要求的低延迟应用，需要全平台支持的场景，推荐JDK21+
   • G1：对吞吐量要求高、延迟要求一般（100-200ms）的中小堆（<32GB）场景，或JDK8及以下版本

2. 问题：分代ZGC和分代Shenandoah哪个更推荐使用？
   答案：JDK21及以上版本优先推荐分代ZGC。它的平均停顿时间更短（<1ms vs <10ms），内存开销更低，且经过Oracle更充分的优化和测试。分代Shenandoah适合需要全平台支持或对Red Hat生态有依赖的场景。

五、调优实践题（高频）

1. 问题：开启ZGC的核心JVM参数有哪些？
   答案：

   # 启用ZGC（JDK15+）
   -XX:+UseZGC
   # 启用分代ZGC（JDK21+，默认开启）
   -XX:+ZGenerational
   # 设置堆大小（建议物理内存的50-70%）
   -Xms16g -Xmx16g
   # 设置GC线程数（默认等于CPU核心数）
   -XX:ConcGCThreads=4
   # 设置最大停顿时间目标（默认200ms，ZGC会尽力满足）
   -XX:MaxGCPauseMillis=5
   # 启用大页支持（强烈推荐，性能提升显著）
   -XX:+UseLargePages
   

2. 问题：如果ZGC的停顿时间过长，应该如何排查和调优？
   答案：

   1. 检查GC日志，确认是哪个STW阶段耗时过长
   2. 若初始标记/最终标记过长：减少GC Roots数量（如减少线程数）
   3. 若并发阶段跟不上应用速度：增加ConcGCThreads数量
   4. 适当调大堆大小，减少GC频率
   5. 启用大页支持，降低内存访问延迟
   6. 升级到最新JDK版本（JDK21+分代ZGC停顿更短）

3. 问题：大堆场景下使用ZGC有哪些最佳实践？
   答案：

   1. 必须使用JDK21及以上版本的分代ZGC
   2. 堆大小建议设置为物理内存的50-70%，避免过小导致频繁GC
   3. 启用大页支持（透明大页或巨页）
   4. GC线程数设置为CPU核心数的1/4-1/2，避免与应用线程竞争
   5. 不要设置过小的MaxGCPauseMillis，否则会导致GC频率过高
   6. 重点监控GC频率、停顿时间和CPU使用率