parnew和parallel old不能组合使用，因其设计目标冲突（低延迟vs高吞吐）、内存分配策略不兼容（指针碰撞vs空闲列表）、屏障协议与实现接口互不匹配。
新生代和老年代垃圾回收器不能随意搭配，不是“能连就配”，而是由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+生产就绪）
