parallel scavenge收集器以高吞吐量为核心目标，采用“少而重”的gc策略，通过并行多线程压缩stw时间，并借助自适应调优动态逼近-gctimeratio设定的吞吐目标，配合parallel old实现端到端吞吐保障。
Parallel Scavenge 收集器追求高吞吐量，核心不是减少单次停顿时间，而是让 JVM 在单位总时间内，尽可能多地运行用户代码。它的策略是“少而重”的 GC：接受稍长的 Stop-The-World（STW）暂停，但大幅降低 GC 发生频率和整体耗时占比。
用并行多线程压缩单次回收耗时
在 STW 阶段，它启用多个 GC 线程并行执行复制操作——比如标记存活对象、将 Eden 区存活对象复制到 Survivor 区、清理死亡对象。线程数默认等于 CPU 物理核心数（≤8 核）或按公式 3 + (5 × 核数) / 8 计算（＞8 核），避免调度开销。多核越强，单次 Minor GC 耗时越短，用户线程“被剥夺”的总时间就越少。
靠自适应策略动态逼近吞吐目标
它不依赖人工硬调参数，而是通过 -XX:+UseAdaptiveSizePolicy（默认开启）持续观察分配速率、晋升行为和 GC 效果，自动调整：
- 年轻代大小（Eden + Survivor 总量）
- Eden 与 Survivor 的比例（SurvivorRatio）
- 对象晋升老年代的年龄阈值
所有这些调整都服务于一个明确目标：让实际 GC 时间占比尽量贴近你设定的 -XX:GCTimeRatio 值。例如设为 99，JVM 就会努力把 GC 总耗时控制在总运行时间的 1% 以内。
配合 Parallel Old 构成端到端吞吐保障
新生代用 Parallel Scavenge（复制算法），老年代默认配 Parallel Old（并行标记-整理算法）。两者都是并行、STW 式，但全程多线程协作，避免 Serial Old 那样的单线程瓶颈。Parallel Old 还能压缩内存碎片，防止因碎片导致的大对象分配失败和意外 Full GC，从老年代层面守住吞吐稳定性。
参数设计直指吞吐本质，不绕弯
它提供最直接的吞吐控制接口，而非间接猜测：
- -XX:GCTimeRatio=n：直接定义 GC 时间上限为 1/(n+1)，是吞吐量的硬性锚点
- -Xms = -Xmx：堆大小固定，消除扩容触发的额外 Full GC 干扰
- 不推荐设 -XX:MaxGCPauseMillis：该参数会迫使 JVM 缩小年轻代、提高 GC 频率，反而拉低吞吐；它只在延迟敏感场景才有意义
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
