选对gc策略本质是平衡吞吐量、延迟和内存footprint；年轻代均采用复制算法，差异在于stw程度与停顿控制能力。
选对 GC 策略，本质是平衡吞吐量、延迟和内存 footprint。没有“最好”的收集器，只有更匹配业务场景的组合。
年轻代回收：复制算法是主流
所有现代 GC 收集器（Serial、Parallel、CMS、G1、ZGC）在年轻代都采用复制算法（Eden + Survivor）。核心逻辑一致：对象在 Eden 分配，Minor GC 时存活对象复制到 Survivor，年龄达标后晋升老年代。差异在于并发能力与线程模型：
- Serial 和 Parallel 是 STW 的——整个年轻代回收期间，应用线程全部暂停；
- G1、ZGC、Shenandoah 在年轻代也 STW，但单次停顿可控（通常
- Survivor 区大小、晋升阈值（-XX:MaxTenuringThreshold）直接影响对象过早进入老年代的风险，需结合 GC 日志中 “Promotion Failed” 或 “tenuring distribution” 调整。
老年代回收：分策略看吞吐 vs 延迟
老年代回收成本高，策略选择直接决定系统响应表现：
- Parallel GC（吞吐优先）：使用标记-整理，STW 时间较长但总耗时短，适合批处理、后台任务等对延迟不敏感的场景；
- CMS（已废弃）：JDK 9 起被标记为 deprecated，JDK 14 彻底移除。曾以并发标记+清除为主，停顿短但易产生碎片、触发 Full GC；
- G1（均衡型）：将堆划分为多个 Region，按预测停顿时间优先回收垃圾最多的区域。兼顾吞吐与延迟（目标停顿
- ZGC / Shenandoah（低延迟）：基于染色指针或转发指针实现几乎全程并发回收，STW 仅毫秒级（ZGC 目标
关键参数影响远超“换收集器”
实际调优中，参数配置常比更换 GC 更有效：
- -Xmn：显式设置年轻代大小。过小 → Minor GC 频繁；过大 → 单次 STW 时间拉长，且可能挤占老年代空间；
- -XX:PretenureSizeThreshold：大对象直接进老年代，避免在年轻代反复复制、引发碎片或提前晋升；
- -XX:G1HeapRegionSize / -XX:MaxGCPauseMillis（G1）：前者控制 Region 大小，影响大对象分配；后者是 G1 的停顿目标，不是硬性保证，但会动态调整回收节奏；
- -XX:+UseStringDeduplication（G1）：减少重复字符串内存占用，对含大量 JSON/文本处理的服务效果明显。
怎么看日志，才能真正判断问题
GC 日志不是只看“有没有 Full GC”，而要读出模式：
- 连续多次 Minor GC 后老年代持续增长 → 可能存在内存泄漏或对象过早晋升；
- Minor GC 频率稳定但每次回收后 Eden 使用率仍高 → 年轻代可能太小；
- G1 日志中频繁出现 “to-space exhausted” 或 “Evacuation Failure” → Region 回收压力大，需调大堆或降低停顿目标；
- ZGC 日志里 “Pause Phases” 时间突增 → 关注是否发生内存分配速率激增或元数据区（Metaspace）压力过大。
