ParNew只能与CMS搭配使用，因其被设计为CMS的新生代搭档，不支持G1、ZGC或Shenandoah；JDK 8u40后单独启用会被忽略并回退至Serial，且CMS已在JDK 14中彻底移除。
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 中曾有用，但现代版本已无此参数）
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
常见错误现象：日志里出现 “ParNew (promotion failed)”
这不是 ParNew 自身失败，而是它尝试把存活对象复制到 Survivor 区时，发现 Survivor 放不下，又无法晋升到老年代（因为老年代碎片太多或已满），最终导致 Full GC。典型诱因：
• -Xmn 设得过大，挤占老年代空间
• -XX:SurvivorRatio 过大（比如设成 12），导致 Survivor 区太小
• CMS 并发周期没跟上对象晋升速度，老年代碎片化严重
• 应用存在内存泄漏，大量中短期对象堆积在老年代
排查时优先看 GC 日志中的 ParNew 后是否紧跟着 Full GC，以及 CMS 是否有 concurrent mode failure 记录
立即学习“Java免费学习笔记（深入）”；
ParNew 的关键限制在于它早已被 JVM 主动边缘化——没有新特性演进，不支持弹性伸缩，也不适配现代容器环境的 CPU 热插拔。现在看到它，基本意味着你在调一个没法轻易升级的遗留系统。
