ParNew收集器特点及与CMS配合使用解析

ParNew收集器本质上是Serial的多线程演进版，但并非通用新生代方案，而是专为CMS老年代收集器定制的“配套组件”，仅在启用CMS（-XX:+UseConcMarkSweepGC）时被自动激活；自JDK 8u40起，单独启用ParNew会被忽略并回退至Serial，而随着CMS在JDK 9中被废弃、JDK 14中彻底移除，ParNew也已退出主流技术栈——如今它只存在于老旧系统的维护场景或历史调优文档中，其线程控制、触发逻辑与常见故障（如promotion failed）均深度绑定CMS的协作机制和固有缺陷，凸显出在现代Java生态中缺乏弹性、无法适配容器化与动态资源环境的根本局限。

ParNew 为什么只能和 CMS 搭配用

ParNew 本质是 Serial 收集器的多线程版本，但它**不支持与 G1、ZGC 或 Shenandoah 配合**，只被设计为 CMS 的“新生代搭档”。JVM 启动时若指定 -XX:+UseConcMarkSweepGC，会自动启用 ParNew；手动加 -XX:+UseParNewGC 却不配 CMS，从 JDK 8u40 起会被忽略，JVM 直接回退到 Serial（并打印警告）。CMS 已在 JDK 9 中被标记为废弃、JDK 14 彻底移除，所以现在用 ParNew 基本只出现在老系统维护或历史调优文档里。

ParNew 的线程数怎么控制

默认线程数等于 CPU 核心数，但实际并发压力下常需手动调优。它不读取 -XX:ParallelGCThreads（那是 Parallel GC 用的），而是依赖 -XX:ParallelGCThreads **在 CMS 场景下被复用**——这点容易混淆。更稳妥的方式是显式设 -XX:+UseParNewGC -XX:ParallelGCThreads=N，N 建议 ≤ CPU 核心数 × 0.75，避免线程过多导致上下文切换开销反超收益。注意：N 设得比物理核数还大，ParNew 不会报错，但 STW 时间可能不降反升。

ParNew 触发时机和 CMS 的配合逻辑

ParNew 是“Stop-The-World”式的新生代收集器，每次触发都会暂停应用线程。它和 CMS 的协作不是自动联动，而是靠 CMS 的触发阈值间接驱动：
• 当老年代空间使用率超过 -XX:CMSInitiatingOccupancyFraction（默认约 68%），CMS 开始并发标记
• 但如果此时新生代频繁 GC（比如 ParNew 次数陡增），说明对象晋升太快，CMS 可能来不及回收老年代，就会发生“concurrent mode failure”——这时 JVM 会退化成 Serial Old 全停顿回收，卡顿明显
• 所以调优重点其实是压低晋升率：调大 -Xmn、用 -XX:SurvivorRatio 控制 S 区大小、避免过早晋升（如关闭 -XX:+HandlePromotionFailure 在 JDK 6–7 中曾有用，但现代版本已无此参数）

常见错误现象：日志里出现 “ParNew (promotion failed)”

这不是 ParNew 自身失败，而是它尝试把存活对象复制到 Survivor 区时，发现 Survivor 放不下，又无法晋升到老年代（因为老年代碎片太多或已满），最终导致 Full GC。典型诱因：
• -Xmn 设得过大，挤占老年代空间
• -XX:SurvivorRatio 过大（比如设成 12），导致 Survivor 区太小
• CMS 并发周期没跟上对象晋升速度，老年代碎片化严重
• 应用存在内存泄漏，大量中短期对象堆积在老年代
排查时优先看 GC 日志中的 ParNew 后是否紧跟着 Full GC，以及 CMS 是否有 concurrent mode failure 记录

以上就是《ParNew收集器特点及与CMS配合使用解析》的详细内容，更多关于的资料请关注golang学习网公众号！