Parallel GC以吞吐量优先，适用于批处理等后台任务；CMS专注低延迟但已废弃，仅限JDK 8–10老系统使用，且易因碎片和浮动垃圾引发长停顿。
Parallel GC 和 CMS 是两种设计目标截然不同的垃圾回收器：前者追求吞吐量，后者专注低延迟。选型不是看“哪个更新”，而是看你的应用真正卡在哪——是整体处理慢（吞吐不足），还是用户点击总卡顿（延迟敏感）。
Parallel GC 适用场景与配置要点
它适合后台任务、批处理、ETL、消息消费等对响应时间不敏感，但要求单位时间内完成更多工作的场景。JDK 8 默认就是它，JDK 9–10 仍广泛使用，直到 G1 成为新默认。
- 启用方式简单：-XX:+UseParallelGC（自动激活 Parallel Old GC）
- 核心调优通常只需控制线程数：-XX:ParallelGCThreads=N（建议设为容器可用 CPU 核数，避免超配）
- 如需兼顾停顿，可加：-XX:MaxGCPauseMillis=200（注意：设太低会牺牲吞吐，得不偿失）
- 推荐搭配自适应策略：-XX:+UseAdaptiveSizePolicy，让 JVM 自动平衡年轻代大小和晋升年龄，比手动调 -Xmn 更稳
- 不用配 -Xmn 或 -XX:NewRatio，否则可能干扰自适应逻辑
CMS 回收器的适用边界与关键配置
CMS 已在 JDK 14 中被正式移除，仅建议仍在 JDK 8/9/10 环境中、且无法升级又确实需要亚秒级停顿的老系统使用。它不是“比 Parallel 更先进”，而是在特定历史阶段的折中方案。
- 启用命令：-XX:+UseConcMarkSweepGC（自动启用 ParNew 做年轻代回收）
- 必须指定并发标记线程数：-XX:ConcGCThreads（建议设为 ParallelGCThreads 的 1/2，而非默认 1/4）
- 触发时机很关键：-XX:CMSInitiatingOccupancyFraction=70（避免等到老年代快满才启动，防止退化为 Serial Old Full GC）
- 加上 -XX:+UseCMSInitiatingOccupancyOnly，禁用 JVM 自动调整触发阈值，保证行为可预测
- 注意：CMS 不做内存整理，长期运行易碎片化；一旦出现 Concurrent Mode Failure，就会触发长时间 Full GC
别踩的典型误判点
很多团队把 CMS 当成“万能低延迟解”，结果在线上翻车。其实它有硬伤：
立即学习“Java免费学习笔记（深入）”；
- 堆小于 4GB 时，CMS 启动开销和并发标记负担反而可能比 Parallel GC 更重
- 大量短生命周期对象 + 少量长生命周期对象的混合场景，CMS 容易因浮动垃圾积累而频繁触发，不如 G1 的 Region 分治机制高效
- 监控看到“CMS initial mark”耗时突增，往往不是 GC 参数问题，而是应用本身在 STW 阶段做了耗时操作（比如同步日志、阻塞 IO）
- 如果已用 JDK 11+，还强行配 CMS，会直接报错或静默降级——它早已不在支持列表里
替代建议：什么情况下该跳过 CMS 直接选 G1
如果你的应用满足以下任一条件，CMS 就不该再是首选：
- 堆内存 ≥ 6GB，且 P99 响应要求 ≤ 500ms
- 运行在 JDK 9 及以上版本（G1 已成熟稳定，且默认启用）
- 存在明显的大对象（≥ 一半 Region 大小），CMS 容易因 Promotion Failure 触发 Full GC
- 运维希望减少调参复杂度——G1 的 -XX:MaxGCPauseMillis 更易收敛，CMS 的 OccupancyFraction 和 ConcGCThreads 组合调优容错率低
