面试考察的是gc在真实场景中的工作逻辑：cms被废弃、g1避免全停顿、zgc实现亚毫秒停顿及业务负载下的取舍；本质是管理对象生命周期，需理解算法设计背后的权衡而非死记参数。
面试中遇到 JVM 垃圾收集器（GC）相关问题，光背参数和算法名称远远不够。面试官真正想考察的是你是否理解 GC 如何在真实场景中工作——比如为什么 CMS 被废弃、G1 如何避免全停顿、ZGC 怎么做到亚毫秒级停顿，以及不同 GC 在不同业务负载下的取舍逻辑。
理解 GC 的本质：不是“回收内存”，而是“管理对象生命周期”
GC 的核心任务不是单纯清理死对象，而是高效协调堆内存分配、对象晋升、跨代引用处理与停顿控制之间的矛盾。比如年轻代采用复制算法，不只是因为“快”，更是因为它天然契合“大部分对象朝生暮死”的统计规律；老年代用标记-整理或标记-清除，则是为应对长生命周期对象的碎片化问题。
- 别只记“Serial 是单线程”，要明白它适合 Client 模式或嵌入式场景——资源受限时，简单可控比吞吐量更重要
- 看到“Parallel GC 吞吐量高”，需意识到它用多线程压缩老年代时仍会 STW，且不保证停顿时间，不适合响应敏感型服务
- 理解 G1 的“分区（Region）+ 预期停顿模型”：它把堆划成小块，每次只选回收价值高、耗时预估低的若干 Region，从而把停顿时间“可预测化”
对比不是罗列，而是讲清设计权衡
面试时被问“G1 和 ZGC 有什么区别”，不要只答“ZGC 更低延迟”。要指出：G1 仍需 Stop-The-World 完成根扫描和部分并发阶段的同步点，而 ZGC 通过着色指针（Colored Pointer）和读屏障（Load Barrier），把绝大部分工作（标记、转移、重映射）都挪到并发阶段，仅保留极短的两次 STW（
- CMS 废弃的关键原因不是“有浮动垃圾”，而是“无法处理并发模式失败（Concurrent Mode Failure）”——当老年代增长过快，CMS 来不及回收就会退化为 Serial Old，造成长时间卡顿
- Shenandoah 的“Brooks Pointer”方案与 ZGC 着色指针路径不同，但目标一致：让对象移动（转发）对用户线程透明，避免 STW 转发
- 选择 GC 不能只看官网宣传指标，要看你的应用特征：短生命周期 + 高吞吐 → Parallel；长请求 + 强响应要求 → ZGC/Shenandoah；大堆 + 可控停顿 → G1
动手调试比背参数更有说服力
说出 -XX:+UseG1GC 是入门，能结合 gc 日志解释一次 Mixed GC 的触发条件（如老年代占用阈值 + 年轻代晋升失败）、识别 RSet 更新瓶颈、或用 jstat 观察 G1 的 Humongous 分配异常，才体现真实经验。
- 用 -Xlog:gc*:file=gc.log:time,tags,level 查看 JDK9+ 统一日志，重点关注 Allocation Stall、Evacuation Failure、To-space Exhausted 等关键事件
- G1 中 Concurrent Cycle 启动时机受 -XX:InitiatingOccupancyPercent 控制，但实际还受上次并发周期完成速度影响——若频繁启动却来不及完成，说明堆增长太快或并发线程数不足（-XX:ConcGCThreads）
- ZGC 的 “Pause Mark Start” 和 “Pause Relocate Start” 是仅有的两个 STW 阶段，前者扫描根，后者准备重定位，它们的耗时稳定在亚毫秒级，可通过 -Xlog:gc+phases=debug 验证
延伸思考：GC 不再是孤立模块
现代 GC 设计越来越依赖底层支持：ZGC 需要 Linux 4.14+ 的多映射（multi-mapping）能力；Shenandoah 依赖 Linux 的 userfaultfd；G1 的 RSet 维护消耗 CPU，可能影响高并发下应用线程调度。这意味着调优不能只盯着 JVM 参数，还要关注 OS 配置、容器内存限制（cgroup v1/v2 对 GC 的影响）、甚至硬件特性（如大页内存对 TLB 命中率的作用）。
- 在 Kubernetes 中运行 ZGC 时，若 cgroup memory limit 设置过紧，可能导致 ZGC 因无法申请足够后备内存而降级为 Full GC
- G1 的 -XX:G1HeapRegionSize 默认由堆大小推导，但若应用大量分配 1MB 左右对象，手动设为 1MB 可减少 Humongous Region 浪费
- 开启 -XX:+UnlockExperimentalVMOptions -XX:+UseEpsilonGC 不是为了生产，而是快速验证：如果去掉 GC，OOM 是不是立刻出现？这能帮你厘清内存泄漏的真实源头
GC 的深度不在参数数量，而在对内存行为、并发模型与系统约束之间张力的理解。能把一次 GC 日志里的每行含义讲清楚，并对应到具体代码行为或部署环境，才算真正过关。
