JDK 17 的 GC：G1 默认，ZGC 与 Shenandoah 转正

G1：区域化与增量回收01

G1 把堆划分成大小相等的 Region（1–32MB，按堆大小取 2 的幂）。对象分配在 Region 中，年轻代只是 Region 的一个逻辑集合，不再要求物理连续。

1. Young GC：回收 Eden 与 Survivor Region，存活对象复制到新的 Survivor 或晋升老年代。
2. 并发标记：老年代占用达到阈值后启动，使用 SATB（Snapshot-At-The-Beginning）记录并发期间的引用变化。
3. Mixed GC：在年轻代回收之外，挑选垃圾比例高的老年代 Region 一起回收。
4. Full GC：并发标记或复制失败时的兜底，通常是全停顿，应尽量避免。

跨 Region 引用由 Remembered Set 记录，避免每次 Young GC 扫描整个老年代。对象大于 Region 一半时按 Humongous 处理，分配在连续的 Humongous Region 中；大数组、大字符串会放大这种开销。

ZGC：染色指针与并发重定位02

ZGC 把标记信息放在指针里（染色指针），而不是对象头。应用线程读取引用时经过 load barrier，根据指针颜色决定是否需要帮忙完成标记或重定位。

1. 并发标记：遍历对象图，把可达性信息写进指针的颜色位。
2. 并发重定位：把存活对象复制到新 Region，旧地址通过转发表记录。
3. 并发重映射：修正仍指向旧地址的引用，使旧空间可回收。
4. 整个过程只有极短的停顿用于根扫描等关键步骤，大部分工作与应用线程并发。

• ZGC 在 17 是单代收集器：没有年轻代/老年代之分，所有周期都针对整个堆。
• 染色指针依赖 64 位地址空间；ZGC 在 17 不支持压缩普通对象指针，引用占用更多内存。
• load barrier 让每次引用读取都多了一点开销；低停顿的代价是吞吐与内存。
• JEP 377 的目标是把停顿控制在 10ms 以内，但这是设计目标，不是任何负载下的保证。

Shenandoah：Brooks 指针03

Shenandoah 也做并发标记与并发 evacuation，但它用 Brooks 指针实现对象转发：每个对象多一个转发指针字，读屏障在访问对象时检查是否已被移动。

两者都追求低停顿，但实现路线不同：ZGC 把元数据放进指针，Shenandoah 把转发状态放进对象。选择时不能只看纸面参数，要看供应商支持、堆规模、分配模式和实测尾延迟。

选择表01

这张表只是起点。真正选择前，用生产相似的堆大小、分配率和对象生命周期做压测，比较 p99 延迟、吞吐、GC CPU 占用和内存足迹。

参数与验证02

# 默认：G1
java -Xmx256m -cp out GcInfo
# maxHeapMB=256
# collector=G1 Young Generation
# collector=G1 Old Generation

# ZGC（17 单代）
java -XX:+UseZGC -Xmx256m -cp out GcInfo
# maxHeapMB=256
# collector=ZGC Cycles
# collector=ZGC Pauses

# Shenandoah
java -XX:+UseShenandoahGC -Xmx256m -cp out GcInfo
# maxHeapMB=256
# collector=Shenandoah Pauses
# collector=Shenandoah Cycles

$ java -XX:+PrintFlagsFinal -version | grep -E "UseG1GC|MaxGCPauseMillis"
    uintx MaxGCPauseMillis                         = 200                                       {product} {default}
     bool UseG1GC                                  = true                                      {product} {ergonomic}

• 用 ManagementFactory.getGarbageCollectorMXBeans() 或 GC 日志确认实际生效的收集器，不要只看启动参数。
• -Xlog:gc*:file=gc.log:time,uptime,level,tags 是 17 推荐的日志写法，替代已弃用的 PrintGCDetails。
• -Xms 与 -Xmx 设成相同值可以避免堆伸缩带来的额外停顿，但是否合适取决于部署密度。
• ZGC / Shenandoah 的并发线程会占用 CPU；容器里要设置合理的 CPU limit，避免 GC 线程与应用线程互相挤压。

排障顺序03

1. 先看 GC 日志：是 Young GC 频繁、Mixed GC 太慢，还是出现了 Full GC。
2. 看分配率与晋升率：年轻代过小会导致对象过早晋升，老年代压力增大。
3. 查大对象：Humongous 分配、超大数组、缓存无上限都会让 G1 退化。
4. 查容器限制：堆设置超过 cgroup 限制会被 OOM Killer 杀掉，不是 GC 问题。
5. 需要低延迟再评估 ZGC / Shenandoah；先确认瓶颈真的在 GC 停顿。
6. 调整后重新压测，比较 p99、吞吐和 CPU，不要只看单次 GC 时间。

先猜再看01

费曼自检：能否讲清因果02