26-Parallel Scavenge 与吞吐量优先上一篇讲了 Serial 和 ParNew它们关注的是缩短单次 GC 停顿。但有一类应用并不在意某次停顿长短而在意单位时间内完成的业务量——例如离线数据分析、批处理任务、ETL 作业。为这类场景HotSpot 提供了Parallel Scavenge / Parallel Old收集器它的设计目标是吞吐量优先。本篇将剖析它的原理、关键参数、自适应调节机制以及它与 ParNew 的本质区别。吞吐量的定义GC 语境下的吞吐量Throughput有精确含义吞吐量 运行用户代码时间 / (运行用户代码时间 GC 时间)注意这不是每秒处理请求数而是用户代码运行时间占总时间的比例。一个 99% 吞吐量的系统意味着 100 秒里有 99 秒在跑业务1 秒在做 GC。举个例子对比延迟优先与吞吐量优先方案A延迟优先每 1 秒 GC 一次每次 10ms → 吞吐量 990/1000 99% 方案B吞吐优先每 10 秒 GC 一次每次 50ms → 吞吐量 9950/10000 99.5%方案 B 单次停顿更长50ms vs 10ms但总 GC 时间更少吞吐量更高。对于不与用户交互的后台任务方案 B 更合适——这正是 Parallel Scavenge 的设计哲学。Parallel Scavenge 收集器Parallel Scavenge 是新生代收集器基于复制算法多线程并行回收回收时 STW。听起来和 ParNew 很像但它有两个关键差异目标不同ParNew 追求降低单次停顿Parallel Scavenge 追求达到可量化的吞吐量。自适应它能根据运行情况动态调整新生代大小、Eden/Survivor 比例、晋升老年代年龄等参数无需人工调参。新生代布局 ┌───────────────────────────────────┐ │ Eden │ S0 │ S1 │ │ (8/10) │(1/10)│(1/10)│ └───────────────────────────────────┘ ↑ 复制算法多线程并行与 ParNew 的本质区别两者表面都是多线程复制算法但底层实现完全不同维度ParNewParallel Scavenge设计目标降低停顿达到吞吐量目标可搭配老年代CMS / Serial OldParallel Old自适应调节无有UseAdaptiveSizePolicy代码框架与 CMS 共享独立实现参数控制停顿为主吞吐量为主最关键的差异是Parallel Scavenge 关注的是吞吐量这个全局指标而不是单次停顿。它允许偶尔一次较长的 GC只要总体 GC 时间占比足够低即可。Parallel Old 收集器Parallel Old 是 Parallel Scavenge 的老年代搭档多线程、Mark-Compact 算法、STW。在 JDK 6 之前Parallel Scavenge 只能搭配 Serial Old单线程老年代导致老年代 GC 成为瓶颈。Parallel Old 的出现让全堆并行吞吐量优先成为可能。# JDK 8 默认收集器组合Server 模式java-XX:UseParallelGC-XX:UseParallelOldGC-cpMyApp com.example.Main实际上 JDK 8 Server 模式下这就是默认组合无需显式指定。JDK 9 起-XX:UseParallelOldGC和-XX:UseParallelGC合并开启一个即同时启用两者。三大核心参数Parallel Scavenge 之所以叫吞吐量优先靠的是下面三个参数的协同。-XX:MaxGCPauseMillis设置最大 GC 停顿时间目标毫秒。JVM 会尽量让单次 GC 停顿不超过这个值方法是缩小新生代——新生代越小回收越快。java-XX:MaxGCPauseMillis50-cpMyApp com.example.Main但这里有个陷阱停顿目标是软约束不是硬保证。JVM 会努力逼近但不保证每次都达标。更危险的是盲目调小这个值会导致新生代被压缩GC 频率上升反而降低吞吐量。MaxGCPauseMillis50 → 新生代缩小 → 单次快但频繁 → 吞吐量下降 MaxGCPauseMillis200 → 新生代扩大 → 单次慢但稀少 → 吞吐量上升这是一个需要根据实际负载权衡的参数。对吞吐量优先的后台任务适当放大停顿目标反而更优。-XX:GCTimeRatio直接以比例方式设定吞吐量目标。GCTimeRatioN表示 GC 时间占总时间的1/(N1)GCTimeRatio99 → 吞吐量目标 99/(991) 99% GCTimeRatio19 → 吞吐量目标 19/(191) 95% GCTimeRatio9 → 吞吐量目标 9/(91) 90%默认值默认值 9 意味着 JVM 默认目标是 90% 吞吐量。对于生产服务偏低通常调到 19 或 99。GCTimeRatio和MaxGCPauseMillis可能冲突——一个要低停顿小新生代一个要高吞吐大新生代。冲突时 JVM 以MaxGCPauseMillis优先这可能导致吞吐量目标无法达成。-XX:UseAdaptiveSizePolicy这是 Parallel Scavenge 最具特色的参数自适应调节。开启后JVM 根据运行历史动态调整新生代 / 老年代大小比例Eden / Survivor 比例对象晋升老年代的年龄阈值java-XX:UseParallelGC-XX:UseAdaptiveSizePolicy\-XX:MaxGCPauseMillis100-XX:GCTimeRatio19\-cpMyApp com.example.Main开启自适应后你只需给出目标停顿或吞吐量JVM 自己找参数。这是声明式调优的早期实践与 G1、ZGC 的设计思路一脉相承。自适应的工作机制JVM 内部维护一组运行统计最近 N 次 GC 的停顿时长、吞吐量、各区域占用。每次 GC 后根据这些统计决定是否调整区域大小if (实测停顿 MaxGCPauseMillis) { 缩小新生代 → 下次 GC 更快 } else if (实测吞吐量 目标吞吐量) { 扩大新生代 → 减少 GC 频率 } // 同时调整 Eden/Survivor 比例、晋升年龄这种反馈机制让 Parallel Scavenge 在负载波动的场景下表现稳健——不需要人工介入JVM 自己会找到平衡点。代码示例观察自适应调节/** * 演示 Parallel Scavenge 自适应调节 * 适用 JDK 8/11/17 * * 运行 * java -Xms256m -Xmx256m -XX:UseParallelGC * -XX:UseAdaptiveSizePolicy * -XX:MaxGCPauseMillis50 -XX:GCTimeRatio19 * -Xlog:gc*info,gcheapdebug -cp MyApp AdaptiveGcDemo */publicclassAdaptiveGcDemo{privatestaticfinalint_1MB1024*1024;publicstaticvoidmain(String[]args)throwsException{// 模拟波动的分配速率for(inti0;i100;i){byte[]blocknewbyte[_1MB];// 偶尔保留引用制造长期存活对象if(i%100){cache(block);}Thread.sleep(20);}}staticfinaljava.util.Listbyte[]CACHEnewjava.util.ArrayList();staticvoidcache(byte[]block){CACHE.add(block);}}观察日志中新生代大小的变化[0.234s][info][gc,heap] GC(0) PSYoungGen total 76288K, used 65536K ... [1.567s][info][gc,heap] GC(5) PSYoungGen total 152576K, used 131072K ... [3.891s][info][gc,heap] GC(12) PSYoungGen total 101376K, used 81920K ...PSYoungGen是 Parallel Scavenge 新生代的内部名PS Parallel Scavenge。可以看到total大小在多次 GC 后发生了变化——这正是自适应调节在起作用。与 ParNew 的选择实际项目中如何在两者间选择决策核心是对停顿还是吞吐更敏感对用户交互的 Web 服务 → 停顿敏感 → ParNew CMSJDK 8或 G1JDK 9 对后台批处理 / ETL → 吞吐敏感 → Parallel Scavenge Parallel Old 对延迟敏感且堆大 → G1 / ZGC一个实际案例某公司夜间跑离线报表每天凌晨 2 点启动一个 Java 进程处理 50GB 数据跑 2 小时。这种场景不与用户交互停顿 200ms 也无所谓。但 2 小时内 GC 总时间越少越好。→Parallel Scavenge Parallel Old是最优解。反过来一个在线 API 服务P99 延迟要求 50ms此时即使吞吐量 99%一次 200ms 的停顿也会打爆 SLA——应选 G1 或 ZGC。适用场景后台计算与批处理Hadoop/Spark 的 JVM 进程MapReduce 任务不与用户交互吞吐量第一。ETL 数据管道定时跑数据清洗只看总耗时。离线训练 / 模型推理批处理对单次延迟不敏感。历史服务JDK 8 默认JDK 8 Server 模式默认就是 Parallel Scavenge Parallel Old。很多遗留系统跑在这套组合上运行多年没出大问题——说明对吞吐不敏感到吞吐重要的中间地带它是可靠的选择。不适用场景交互式 Web 服务停顿不可控可能突然出现 200ms 的长尾。低延迟交易系统单次停顿超 10ms 就会影响交易。大堆 8GBParallel Old 整理老年代时全堆 STW堆越大停顿越长。实践要点1. 不要同时设 MaxGCPauseMillis 和 GCTimeRatio 且相互矛盾# 矛盾配置要 50ms 停顿又要 99% 吞吐-XX:MaxGCPauseMillis50-XX:GCTimeRatio99JVM 会以MaxGCPauseMillis优先GCTimeRatio形同虚设。选一个作为主目标即可。2. 自适应开启后不要手动固定新生代# 错误开了自适应又固定新生代-XX:UseAdaptiveSizePolicy-Xmn100m-Xmn或-XX:NewRatio会和自适应冲突。开启自适应后让 JVM 自己管区域大小。3. 监控 GC 频率而非单次停顿吞吐量优先场景下单次停顿波动正常。关注单位时间内 GC 总时间和吞吐量百分比这两个指标更能反映健康度。JDK 11 日志会在每次 GC 后输出User/Sys/Real时间可据此计算。4. Parallel Old 的 Full GC 是 STW 的[12.345s][info][gc]GC(20)Pause Full(Ergonomics)800M-600M(1G)234.567ms(Ergonomics)表示触发原因是自适应策略决定该做 Full GC 了。注意 Full GC 停顿随堆线性增长4GB 堆可能轻松到秒级。大堆场景应迁移到 G1。5. JDK 8 升级到 JDK 11 时的迁移JDK 11 默认 G1若你的批处理任务在 JDK 8 用 Parallel Scavenge 表现良好可以显式保留java-XX:UseParallelGC-cpMyApp com.example.BatchJob对于批处理任务不必盲目切 G1——Parallel Scavenge 的吞吐量优势在纯计算场景下依然存在。小结Parallel Scavenge / Parallel Old是吞吐量优先的收集器组合新生代复制算法、老年代 Mark-Compact全多线程并行。吞吐量 用户代码时间 / (用户代码时间 GC 时间)与低停顿是不同的优化目标后者允许总 GC 时间更多。三大核心参数MaxGCPauseMillis停顿目标、GCTimeRatio吞吐量目标、UseAdaptiveSizePolicy自适应开关三者协同让 JVM 自行寻优。与 ParNew 的本质区别在于设计目标和自适应能力代码实现也相互独立二者不可混搭。适用场景后台批处理、离线数据分析、ETL 作业等不与用户交互的吞吐量敏感型任务交互式 Web 服务应选 G1 或 ZGC。下一篇我们将进入垃圾收集器的并发时代——CMS 收集器它是第一款真正让老年代回收与应用线程并发的收集器也是理解 G1、ZGC 并发回收思路的关键阶梯。更多内容JVM调优实战
26-Parallel Scavenge 与吞吐量优先上一篇讲了 Serial 和 ParNew它们关注的是缩短单次 GC 停顿。但有一类应用并不在意某次停顿长短而在意单位时间内完成的业务量——例如离线数据分析、批处理任务、ETL 作业。为这类场景HotSpot 提供了Parallel Scavenge / Parallel Old收集器它的设计目标是吞吐量优先。本篇将剖析它的原理、关键参数、自适应调节机制以及它与 ParNew 的本质区别。吞吐量的定义GC 语境下的吞吐量Throughput有精确含义吞吐量 运行用户代码时间 / (运行用户代码时间 GC 时间)注意这不是每秒处理请求数而是用户代码运行时间占总时间的比例。一个 99% 吞吐量的系统意味着 100 秒里有 99 秒在跑业务1 秒在做 GC。举个例子对比延迟优先与吞吐量优先方案A延迟优先每 1 秒 GC 一次每次 10ms → 吞吐量 990/1000 99% 方案B吞吐优先每 10 秒 GC 一次每次 50ms → 吞吐量 9950/10000 99.5%方案 B 单次停顿更长50ms vs 10ms但总 GC 时间更少吞吐量更高。对于不与用户交互的后台任务方案 B 更合适——这正是 Parallel Scavenge 的设计哲学。Parallel Scavenge 收集器Parallel Scavenge 是新生代收集器基于复制算法多线程并行回收回收时 STW。听起来和 ParNew 很像但它有两个关键差异目标不同ParNew 追求降低单次停顿Parallel Scavenge 追求达到可量化的吞吐量。自适应它能根据运行情况动态调整新生代大小、Eden/Survivor 比例、晋升老年代年龄等参数无需人工调参。新生代布局 ┌───────────────────────────────────┐ │ Eden │ S0 │ S1 │ │ (8/10) │(1/10)│(1/10)│ └───────────────────────────────────┘ ↑ 复制算法多线程并行与 ParNew 的本质区别两者表面都是多线程复制算法但底层实现完全不同维度ParNewParallel Scavenge设计目标降低停顿达到吞吐量目标可搭配老年代CMS / Serial OldParallel Old自适应调节无有UseAdaptiveSizePolicy代码框架与 CMS 共享独立实现参数控制停顿为主吞吐量为主最关键的差异是Parallel Scavenge 关注的是吞吐量这个全局指标而不是单次停顿。它允许偶尔一次较长的 GC只要总体 GC 时间占比足够低即可。Parallel Old 收集器Parallel Old 是 Parallel Scavenge 的老年代搭档多线程、Mark-Compact 算法、STW。在 JDK 6 之前Parallel Scavenge 只能搭配 Serial Old单线程老年代导致老年代 GC 成为瓶颈。Parallel Old 的出现让全堆并行吞吐量优先成为可能。# JDK 8 默认收集器组合Server 模式java-XX:UseParallelGC-XX:UseParallelOldGC-cpMyApp com.example.Main实际上 JDK 8 Server 模式下这就是默认组合无需显式指定。JDK 9 起-XX:UseParallelOldGC和-XX:UseParallelGC合并开启一个即同时启用两者。三大核心参数Parallel Scavenge 之所以叫吞吐量优先靠的是下面三个参数的协同。-XX:MaxGCPauseMillis设置最大 GC 停顿时间目标毫秒。JVM 会尽量让单次 GC 停顿不超过这个值方法是缩小新生代——新生代越小回收越快。java-XX:MaxGCPauseMillis50-cpMyApp com.example.Main但这里有个陷阱停顿目标是软约束不是硬保证。JVM 会努力逼近但不保证每次都达标。更危险的是盲目调小这个值会导致新生代被压缩GC 频率上升反而降低吞吐量。MaxGCPauseMillis50 → 新生代缩小 → 单次快但频繁 → 吞吐量下降 MaxGCPauseMillis200 → 新生代扩大 → 单次慢但稀少 → 吞吐量上升这是一个需要根据实际负载权衡的参数。对吞吐量优先的后台任务适当放大停顿目标反而更优。-XX:GCTimeRatio直接以比例方式设定吞吐量目标。GCTimeRatioN表示 GC 时间占总时间的1/(N1)GCTimeRatio99 → 吞吐量目标 99/(991) 99% GCTimeRatio19 → 吞吐量目标 19/(191) 95% GCTimeRatio9 → 吞吐量目标 9/(91) 90%默认值默认值 9 意味着 JVM 默认目标是 90% 吞吐量。对于生产服务偏低通常调到 19 或 99。GCTimeRatio和MaxGCPauseMillis可能冲突——一个要低停顿小新生代一个要高吞吐大新生代。冲突时 JVM 以MaxGCPauseMillis优先这可能导致吞吐量目标无法达成。-XX:UseAdaptiveSizePolicy这是 Parallel Scavenge 最具特色的参数自适应调节。开启后JVM 根据运行历史动态调整新生代 / 老年代大小比例Eden / Survivor 比例对象晋升老年代的年龄阈值java-XX:UseParallelGC-XX:UseAdaptiveSizePolicy\-XX:MaxGCPauseMillis100-XX:GCTimeRatio19\-cpMyApp com.example.Main开启自适应后你只需给出目标停顿或吞吐量JVM 自己找参数。这是声明式调优的早期实践与 G1、ZGC 的设计思路一脉相承。自适应的工作机制JVM 内部维护一组运行统计最近 N 次 GC 的停顿时长、吞吐量、各区域占用。每次 GC 后根据这些统计决定是否调整区域大小if (实测停顿 MaxGCPauseMillis) { 缩小新生代 → 下次 GC 更快 } else if (实测吞吐量 目标吞吐量) { 扩大新生代 → 减少 GC 频率 } // 同时调整 Eden/Survivor 比例、晋升年龄这种反馈机制让 Parallel Scavenge 在负载波动的场景下表现稳健——不需要人工介入JVM 自己会找到平衡点。代码示例观察自适应调节/** * 演示 Parallel Scavenge 自适应调节 * 适用 JDK 8/11/17 * * 运行 * java -Xms256m -Xmx256m -XX:UseParallelGC * -XX:UseAdaptiveSizePolicy * -XX:MaxGCPauseMillis50 -XX:GCTimeRatio19 * -Xlog:gc*info,gcheapdebug -cp MyApp AdaptiveGcDemo */publicclassAdaptiveGcDemo{privatestaticfinalint_1MB1024*1024;publicstaticvoidmain(String[]args)throwsException{// 模拟波动的分配速率for(inti0;i100;i){byte[]blocknewbyte[_1MB];// 偶尔保留引用制造长期存活对象if(i%100){cache(block);}Thread.sleep(20);}}staticfinaljava.util.Listbyte[]CACHEnewjava.util.ArrayList();staticvoidcache(byte[]block){CACHE.add(block);}}观察日志中新生代大小的变化[0.234s][info][gc,heap] GC(0) PSYoungGen total 76288K, used 65536K ... [1.567s][info][gc,heap] GC(5) PSYoungGen total 152576K, used 131072K ... [3.891s][info][gc,heap] GC(12) PSYoungGen total 101376K, used 81920K ...PSYoungGen是 Parallel Scavenge 新生代的内部名PS Parallel Scavenge。可以看到total大小在多次 GC 后发生了变化——这正是自适应调节在起作用。与 ParNew 的选择实际项目中如何在两者间选择决策核心是对停顿还是吞吐更敏感对用户交互的 Web 服务 → 停顿敏感 → ParNew CMSJDK 8或 G1JDK 9 对后台批处理 / ETL → 吞吐敏感 → Parallel Scavenge Parallel Old 对延迟敏感且堆大 → G1 / ZGC一个实际案例某公司夜间跑离线报表每天凌晨 2 点启动一个 Java 进程处理 50GB 数据跑 2 小时。这种场景不与用户交互停顿 200ms 也无所谓。但 2 小时内 GC 总时间越少越好。→Parallel Scavenge Parallel Old是最优解。反过来一个在线 API 服务P99 延迟要求 50ms此时即使吞吐量 99%一次 200ms 的停顿也会打爆 SLA——应选 G1 或 ZGC。适用场景后台计算与批处理Hadoop/Spark 的 JVM 进程MapReduce 任务不与用户交互吞吐量第一。ETL 数据管道定时跑数据清洗只看总耗时。离线训练 / 模型推理批处理对单次延迟不敏感。历史服务JDK 8 默认JDK 8 Server 模式默认就是 Parallel Scavenge Parallel Old。很多遗留系统跑在这套组合上运行多年没出大问题——说明对吞吐不敏感到吞吐重要的中间地带它是可靠的选择。不适用场景交互式 Web 服务停顿不可控可能突然出现 200ms 的长尾。低延迟交易系统单次停顿超 10ms 就会影响交易。大堆 8GBParallel Old 整理老年代时全堆 STW堆越大停顿越长。实践要点1. 不要同时设 MaxGCPauseMillis 和 GCTimeRatio 且相互矛盾# 矛盾配置要 50ms 停顿又要 99% 吞吐-XX:MaxGCPauseMillis50-XX:GCTimeRatio99JVM 会以MaxGCPauseMillis优先GCTimeRatio形同虚设。选一个作为主目标即可。2. 自适应开启后不要手动固定新生代# 错误开了自适应又固定新生代-XX:UseAdaptiveSizePolicy-Xmn100m-Xmn或-XX:NewRatio会和自适应冲突。开启自适应后让 JVM 自己管区域大小。3. 监控 GC 频率而非单次停顿吞吐量优先场景下单次停顿波动正常。关注单位时间内 GC 总时间和吞吐量百分比这两个指标更能反映健康度。JDK 11 日志会在每次 GC 后输出User/Sys/Real时间可据此计算。4. Parallel Old 的 Full GC 是 STW 的[12.345s][info][gc]GC(20)Pause Full(Ergonomics)800M-600M(1G)234.567ms(Ergonomics)表示触发原因是自适应策略决定该做 Full GC 了。注意 Full GC 停顿随堆线性增长4GB 堆可能轻松到秒级。大堆场景应迁移到 G1。5. JDK 8 升级到 JDK 11 时的迁移JDK 11 默认 G1若你的批处理任务在 JDK 8 用 Parallel Scavenge 表现良好可以显式保留java-XX:UseParallelGC-cpMyApp com.example.BatchJob对于批处理任务不必盲目切 G1——Parallel Scavenge 的吞吐量优势在纯计算场景下依然存在。小结Parallel Scavenge / Parallel Old是吞吐量优先的收集器组合新生代复制算法、老年代 Mark-Compact全多线程并行。吞吐量 用户代码时间 / (用户代码时间 GC 时间)与低停顿是不同的优化目标后者允许总 GC 时间更多。三大核心参数MaxGCPauseMillis停顿目标、GCTimeRatio吞吐量目标、UseAdaptiveSizePolicy自适应开关三者协同让 JVM 自行寻优。与 ParNew 的本质区别在于设计目标和自适应能力代码实现也相互独立二者不可混搭。适用场景后台批处理、离线数据分析、ETL 作业等不与用户交互的吞吐量敏感型任务交互式 Web 服务应选 G1 或 ZGC。下一篇我们将进入垃圾收集器的并发时代——CMS 收集器它是第一款真正让老年代回收与应用线程并发的收集器也是理解 G1、ZGC 并发回收思路的关键阶梯。更多内容JVM调优实战
