Parallel Scavenge收集器的核心目标是高吞吐量，即通过并行回收、自适应调节和-XX:GCTimeRatio参数直接控制GC时间占比，优先保障用户代码运行时间，适用于后台批处理等CPU密集型场景。
Parallel Scavenge 收集器的高吞吐量设计，核心在于把“用户代码运行时间占比”作为直接优化目标，而不是把单次停顿时间压到最短。它不回避 Stop-The-World，但通过并行、自适应和参数化控制，让 GC 总耗时在单位时间内尽可能少，从而把 CPU 时间更多留给业务逻辑。
吞吐量是明确可设的目标值
它不像其他收集器那样靠调优“逼近”某个效果，而是用 -XX:GCTimeRatio=n 直接声明目标：GC 时间不能超过总时间的 1/(n+1)。比如设为 99，就表示允许 GC 占比 ≤1%，即吞吐量目标为 99%。JVM 会围绕这个硬指标动态调节内存布局和回收节奏，不是靠经验猜，而是按公式执行。
并行复制 + 并行标记整理，匹配批处理特征
新生代用多线程复制算法，Eden 区一扫即清，适合科学计算、ETL 等短生命周期对象密集分配的场景；老年代搭配 Parallel Old，用并行标记-整理，既避免碎片又支持大对象连续分配。整套流程没有并发阶段，全部 STW，但因并行执行，在 4–8GB 堆规模下仍能保持可控暂停，换来的是一致的高吞吐效率。
自适应策略自动平衡资源分配
默认开启的 -XX:+UseAdaptiveSizePolicy 让 JVM 自己学习内存行为：根据对象晋升速率、Survivor 空间使用率、GC 频次等实时反馈，动态调整年轻代大小、Survivor 比例、晋升年龄阈值。你不用手动设 -Xmn 或 -SurvivorRatio，只要给定堆上下限（-Xms = -Xmx），它就能持续优化到吞吐最优状态。
不为低延迟妥协，适用边界清晰
它主动接受较长但较少的 STW，拒绝为压缩单次停顿而牺牲整体吞吐。因此：
• 不建议设置 -XX:MaxGCPauseMillis，否则会强制缩小年轻代，导致 Minor GC 更频繁，反而拉低吞吐；
• 不适合 Web 服务、实时接口等对响应延迟敏感的系统；
• 专为后台批处理、报表生成、仿真计算等长周期、CPU 密集、无交互任务而生。
