JVM默认垃圾收集器随JDK版本演进：JDK 7/8默认Parallel GC（高吞吐、长停顿）；JDK 9起默认G1（可预测停顿、兼顾大堆与低碎片）；ZGC/Shenandoah虽引入但未取代G1，默认仍为G1。
JVM 默认垃圾收集器的切换不是随意调整，而是围绕“吞吐量—延迟—内存规模”三者权衡的结果。不同版本 JDK 面对的应用场景、硬件条件和用户诉求发生了明显变化，推动 GC 策略持续演进。
JDK 7 和 JDK 8：Parallel GC 是默认选择
这两个版本默认使用 Parallel Scavenge（新生代） + Parallel Old（老年代） 组合，统称 Parallel GC。
- 设计目标明确：以高吞吐量为第一优先级，适合后台批处理、科学计算等长时间运行、不敏感于单次停顿的场景。
- 算法组合务实：新生代用复制算法保证分配效率，老年代用标记-整理减少碎片，但会带来较长的 Stop-The-World 时间。
- 当时主流应用堆内存普遍在 2–4GB，CMS 尚未成为标配，G1 处于实验阶段（JDK 6 引入，JDK 7/8 可手动启用但不默认）。
JDK 9 开始：G1 成为默认，核心动因是“可预测停顿”
从 JDK 9 起，G1（Garbage-First）正式取代 Parallel GC 成为默认回收器，这一变更延续至 JDK 17（含）。
- 硬件与应用变化倒逼升级：服务器内存普遍突破 6GB，微服务架构兴起，用户对响应延迟愈发敏感——Parallel GC 的长停顿难以接受，而 CMS 在 JDK 9 中已被标记为废弃。
- G1 的分区（Region）机制天然支持增量回收：它不强制清理整个老年代，而是挑选垃圾比例最高的 Region 优先回收，从而把停顿时间控制在目标范围内（默认 -XX:MaxGCPauseMillis=200ms）。
- 兼顾大堆与低碎片：G1 同时管理年轻代和老年代，混合回收中自动执行压缩，避免了 CMS 的内存碎片恶化问题。
JDK 11 到 JDK 17：ZGC 和 Shenandoah 加入，但 G1 仍守默认地位
虽然 JDK 11 引入 ZGC（亚毫秒停顿）、JDK 12 引入 Shenandoah（并发压缩），它们在超低延迟场景表现突出，但并未替代 G1 成为默认回收器。
- ZGC 和 Shenandoah 属于“新锐选手”，初期稳定性、兼容性、监控工具链支持不如 G1 成熟；JDK 11 中 ZGC 是实验特性，JDK 15 才转为生产就绪。
- G1 经过多年迭代（JDK 9–17 共 9 个主版本），已具备成熟调优手段、丰富监控指标（如 G1EvacuationPause、G1MixedGCPause）和广泛运维经验，仍是大多数服务端应用的稳妥之选。
- 默认策略讲求“开箱即用”的平衡：G1 在 4–64GB 堆范围内的延迟与吞吐表现足够均衡，而 ZGC 更适合 TB 级堆或金融高频交易等极端场景，需显式启用（-XX:+UseZGC）。
如何验证当前 JDK 使用的默认 GC？
最直接的方式是运行：
java -XX:+PrintCommandLineFlags -version
输出中会明确显示类似 -XX:+UseG1GC 或 -XX:+UseParallelGC 的参数。也可通过 JMX 或 jstat -gc <pid> 观察 GC 日志中的收集器名称。
