java gc选择核心是匹配业务对延迟、吞吐、内存的权重需求：延迟敏感选zgc（≤10ms）、shenandoah或g1（≤200ms）；吞吐优先选parallel gc；小堆（≤1gb）适用serial gc；需结合jdk版本、堆大小与对象生命周期调优。
评估 Java 垃圾回收器（GC）的适用场景，核心是看应用对延迟（Latency）、吞吐量（Throughput）、内存占用（Footprint）这三者的实际需求权重，再结合 JVM 版本、堆结构、对象生命周期特征来匹配。不是“哪个最强”，而是“哪个最贴合”。
看延迟敏感度：选低暂停时间回收器
若应用要求响应快、不能容忍长停顿（如金融交易、实时风控、Web API 服务），优先考虑以减少 STW（Stop-The-World）时间为设计目标的回收器：
- ZGC（JDK 11+）：目标是停顿控制在 10ms 内，支持 TB 级堆，适合大堆 + 严苛延迟场景；但需 JDK 11 或更高版本，且对部分老系统兼容性需验证。
- Shenandoah（JDK 12+，JDK 15 起默认启用）：同样主打亚毫秒到几毫秒级停顿，与 ZGC 类似，但 GC 算法细节不同，某些负载下表现更稳；对 CPU 消耗略高，适合内存充足、CPU 有余量的环境。
-
G1（JDK 9 默认，现仍广泛使用）：可设
-XX:MaxGCPauseMillis目标，适合中等延迟要求（如 50–200ms）；对大堆（数 GB 到数十 GB）适应性好，调优经验成熟。
看吞吐量优先级：选高效率回收器
若后台批处理、科学计算、离线分析类应用，更看重单位时间内完成的工作量（即吞吐量），可接受稍长但可控的 GC 暂停：
- Parallel GC（吞吐量收集器）：多线程并行回收，STW 时间可能较长（几百毫秒甚至秒级），但总吞吐量高；适合 CPU 密集、无强交互、堆中等（几 GB）、JVM 版本较旧（如 JDK 8）的场景。
- 注意：它不追求低延迟，也不适合小堆频繁分配的场景；若误用于 Web 应用，容易引发明显卡顿。
看堆大小与对象生命周期特征
回收器效果受实际内存行为影响很大，需观察运行时数据：
-
年轻代对象存活率高？——说明对象“变老快”，G1 或 ZGC 的混合回收机制比 Parallel GC 更适应；可配合
-XX:+PrintGCDetails查看 Eden/Survivor 晋升比例。 - 堆大于 64GB 且碎片多？——G1 可能出现并发模式失败（Concurrent Mode Failure），ZGC/Shenandoah 因基于颜色指针和读屏障，天然规避碎片问题。
- 小堆（——Serial GC（单线程）开销极小，嵌入式或测试环境反而更轻量；无需强行上 G1。
看运维与兼容性现实约束
生产选型不能只看理论指标：
- JDK 版本锁死在 8？——只能从 Parallel、CMS（已废弃）、G1 中选；CMS 虽低延迟但易失败且不维护，G1 是更稳妥的选择。
- 监控工具是否支持新 GC？——ZGC 的 GC 日志格式与传统不同，Prometheus + jvm_exporter 等需新版适配；日志解析脚本也需更新。
- 是否允许预热与调优周期？——ZGC 和 Shenandoah 虽先进，但初始配置不当（如未预留足够元空间或堆外内存）可能引发意外 OOM；建议先在预发压测对比。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
