Parallel收集器通过多线程并行执行STW阶段的标记、复制和整理任务，在多核CPU上压缩单次GC耗时，从而提升吞吐量；它默认启用自适应策略，年轻代用Parallel Scavenge（复制算法），老年代用Parallel Old（标记-整理算法），适用于批处理、后台计算等吞吐优先场景。
Parallel收集器在多核CPU上能显著提升吞吐量，核心在于它用多个GC线程并行执行Stop-The-World阶段的任务，把原本单线程串行完成的标记、复制、整理等工作分摊到多个CPU核心上。这意味着单次GC耗时缩短，单位时间内应用线程运行时间占比更高，吞吐量自然上升。
多核环境下吞吐量提升的关键机制
Parallel GC不是靠减少停顿次数，而是靠压缩单次停顿时间来换取更多有效运行时间。它默认启用自适应策略（-XX:+UseAdaptiveSizePolicy），会动态调整年轻代大小、Survivor比例等参数，配合多线程并行回收，让堆内存分配和回收节奏更贴合实际负载。
- 年轻代使用Parallel Scavenge，基于复制算法，多线程同步将Eden中存活对象复制到Survivor区
- 老年代使用Parallel Old，采用标记-整理算法，避免内存碎片，也由多线程并行完成
- GC线程数默认按CPU核数计算：核数≤8时等于核数；核数＞8时为3 + (5×核数)/8，避免线程过多引发调度开销
适合Parallel GC的典型业务场景
它不追求毫秒级响应，而是保障单位时间处理任务总量最大化。这类应用通常具备“可容忍短暂停顿、但不能长期低效”的特征。
- 批量数据处理：如日终对账、报表生成、ETL任务，一次运行持续数分钟，几百毫秒STW影响极小
- 后台计算服务：科学仿真、图像渲染、风控模型评分，CPU密集、IO等待少，吞吐压倒一切
- 离线定时作业：工资发放、库存盘点、邮件推送，有明确执行窗口，对延迟不敏感
调优时需关注的几个硬性约束
Parallel GC的参数调节本质是在吞吐量、停顿时间和内存占用之间找平衡点，不能脱离硬件与业务实际拍脑袋设值。
- -XX:MaxGCPauseMillis只是软目标，设得太低会导致GC频繁触发小堆回收，反而降低吞吐；建议从200ms起步，结合GC日志观察实际效果
- -XX:GCTimeRatio=19表示允许GC时间最多占5%（1/(1+19)），比默认99（即1%）更宽松，适合对吞吐要求极端严格的场景
- 堆大小建议固定（-Xms = -Xmx），避免动态扩容带来的额外开销；年轻代比例可通过
-XX:NewRatio或直接用-XX:MaxNewSize控制
为什么不是所有多核服务都该选Parallel
它只适合“GC停顿可接受”的系统。如果服务面向终端用户、SLA要求P99响应
