新老回收器组合详解与搭配技巧

JVM中新生代与老年代垃圾回收器的组合绝非随意搭配，而是受内存管理策略、同步机制、对象晋升路径及GC接口契约等底层设计严格约束——例如ParNew与Parallel Old虽同为并行回收器，却因目标冲突（低延迟vs高吞吐）、分配策略不兼容（指针碰撞vs空闲列表）及屏障协议互斥而无法共存；目前官方稳定支持的组合仅有Serial+Serial Old、Parallel Scavenge+Parallel Old、ParNew+CMS（已逐步淘汰）以及自成一体的G1，而曾短暂存在的Serial+CMS组合也因根本性设计矛盾被彻底移除；选择回收器组合本质上是在权衡系统SLA：批处理重吞吐、Web服务重响应、资源受限看轻量、大堆强一致选G1或ZGC——理解这些约束与取舍，才是高效调优JVM内存的关键起点。

新生代和老年代垃圾回收器不能随意搭配，不是“能连就配”，而是由JVM底层设计严格限定的。能否组合，取决于内存管理策略、同步机制、对象晋升路径和GC接口契约是否一致。

哪些组合是官方支持且稳定的

JVM明确允许以下主流组合，它们在源码层有完整适配：

• Serial + Serial Old：最基础的串行组合，单线程、STW明显，适合小堆或嵌入式场景
• Parallel Scavenge + Parallel Old：JDK 8 默认组合，吞吐量优先，两者共享自适应调优逻辑（如 -XX:+UseAdaptiveSizePolicy）
• ParNew + CMS：低延迟组合，CMS专为配合ParNew设计，共享卡表（Card Table）和写屏障协议
• G1：独立整堆收集器，不区分新生代/老年代回收器，自身完成分代+分区回收

Serial + CMS 曾短暂存在，但已被淘汰

该组合在早期JDK（如6uX）中技术上可启用（-XX:+UseSerialGC -XX:+UseConcMarkSweepGC），但存在根本性冲突：

• Serial使用指针碰撞分配，CMS要求空闲列表管理——内存分配策略不兼容
• CMS依赖并发标记阶段的写屏障更新卡表，而Serial无对应屏障支持，易导致漏标
• JDK 8 中已将该组合标记为废弃，JDK 9 起完全移除支持

为什么 ParNew 和 Parallel Old 无法共存

表面都是“并行”，实则目标与实现割裂：

• 目标错位：ParNew为配合CMS降低停顿时间；Parallel Old为匹配Parallel Scavenge追求吞吐量
• 内存布局冲突：ParNew默认用指针碰撞分配Eden；Parallel Old依赖空闲列表管理老年代碎片，晋升对象时无法安全交接
• 屏障协议不互通：ParNew需CMS风格的增量更新屏障（IU-barrier），Parallel Old只响应吞吐量导向的批量屏障

选组合，本质是选SLA取向

没有“最强”，只有“最适配”：

• 后台批处理任务 → Parallel Scavenge + Parallel Old（稳吞吐、易调参）
• Web服务、实时API → ParNew + CMS（已弃用）或升级为 G1 / ZGC（低延迟首选）
• 资源受限环境（如IoT）→ Serial + Serial Old（零并发开销）
• 大堆+强一致性要求 → G1（JDK 9+默认）或 ZGC（JDK 11+实验性，JDK 15+生产就绪）

以上就是《新老回收器组合详解与搭配技巧》的详细内容，更多关于的资料请关注golang学习网公众号！