核心是匹配应用特征与jvm目标：吞吐量优先选parallel scavenge+serial old（适合批处理）；停顿敏感则选g1或zgc（如web api需≤100ms）。
选择垃圾收集器组合的核心逻辑是：**匹配应用特征与 JVM 运行目标**，而非套用固定公式。关键看吞吐量要求、停顿敏感度、堆结构、硬件资源和 JDK 版本限制。
看吞吐量优先还是响应时间优先
Parallel Scavenge + Serial Old 组合本质是“吞吐量优先”设计：年轻代用多线程并行回收（Parallel Scavenge），老年代用单线程串行回收（Serial Old）。它适合后台批处理、定时任务等可接受较长 GC 停顿（几百毫秒甚至秒级）、但要求长时间内 CPU 利用率高、总吞吐量大的场景。如果应用对单次停顿敏感（如 Web API、实时交易），这种组合就不合适——Serial Old 在老年代回收时会触发全局 Stop-The-World，且无法并发执行。
- 吞吐量目标明确（如 -XX:MaxGCPauseMillis 不设或设得宽松），选 Parallel Scavenge 系列（+ Parallel Old 更现代）
- 要求平均停顿 ≤ 100ms 且波动小，优先考虑 G1 或 ZGC（JDK 11+）
- 超低延迟（
看老年代回收是否成为瓶颈
Serial Old 是单线程、标记-整理算法，老年代越大，停顿越长，且无法利用多核。当应用存在大量长期存活对象、老年代增长快、Full GC 频繁时，Serial Old 会迅速成为瓶颈。此时即使年轻代回收高效，整体 GC 性能仍被拖累。
Java JDK 25 来自 OpenJDK 官方归档，版本为 JDK 25，本条下载地址已指向官方 Windows x64 zip 安装包直链，适合调试旧项目或兼容旧版 Java 运行环境。
- 老年代 ≥ 2GB 且 Full GC 每小时发生多次 → 避免 Serial Old，改用 Parallel Old（吞吐导向）或 G1（平衡导向）
- 使用 CMS（已废弃）或 G1 时，年轻代必须搭配对应老年代收集器，不能混搭（如 Parallel Scavenge + G1Old 不合法）
- JDK 8u212+ 默认启用 G1；JDK 9+ 移除 PermGen 后，CMS 被标记废弃；JDK 14+ 彻底移除 CMS
看 JDK 版本与默认策略演进
组合有效性高度依赖 JDK 版本。例如 Parallel Scavenge + Serial Old 在 JDK 7/8 中常见，但 JDK 9 开始默认启用 G1，JDK 17+ 中 ZGC 进入生产就绪状态。盲目沿用旧组合可能错过更优方案或触发兼容性警告。
- JDK 8：可用 Parallel Scavenge + Parallel Old（推荐替代 Serial Old），或 CMS（需显式开启）
- JDK 9–15：G1 是默认且主流选择，自动适配堆大小与暂停目标
- JDK 17+：ZGC 支持最大 16TB 堆，停顿稳定在毫秒级，适合大堆低延迟场景
- 所有组合需通过 -XX:+PrintGCDetails 和 GC 日志验证实际行为，不能仅凭参数推断
看是否需要自适应调优能力
Parallel Scavenge 系列提供 -XX:MaxGCPauseMillis 和 -XX:GCTimeRatio 等目标驱动参数，JVM 会动态调整年轻代大小、晋升阈值等以逼近目标。但 Serial Old 完全不参与该调节，老年代行为不可控。G1 和 ZGC 则整堆统一建模，支持跨代预测与增量回收，调优粒度更细、反馈更及时。
- 希望 JVM 自动平衡吞吐与停顿 → 选 G1 或 ZGC，避免手动分代调优
- 需精确控制 GC 发生时机（如配合业务低峰期）→ Parallel Scavenge 的确定性更强
- 监控发现 Promotion Rate 波动大、Survivor 空间频繁溢出 → 可能需切换为 G1 的增量晋升机制
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
