Parallel Scavenge与Parallel Old是专为高吞吐量设计的并行GC组合，新生代用并行复制算法，老年代用并行标记-整理算法，适合批处理等延迟不敏感场景，但不适用于实时交互服务。
Parallel Scavenge 与 Parallel Old 是一套专为高吞吐量设计的并行垃圾收集组合，不追求单次停顿短，而是让 JVM 在单位时间内尽可能多地执行用户代码。它适合批处理、离线计算等对响应延迟不敏感、但对整体运行效率要求高的场景。
新生代用 Parallel Scavenge：并行复制，清空即走
Parallel Scavenge 负责新生代回收，采用多线程并行的复制算法。Eden 区对象在 Minor GC 时被扫描，存活对象复制到 Survivor 区（或直接晋升），死亡对象直接丢弃，回收后 Eden 区完全清空，无内存碎片。这种机制天然适配短生命周期对象居多的场景。
- 默认启用（JDK 8 及以前），通过 -XX:+UseParallelGC 显式开启
- 线程数由 -XX:ParallelGCThreads 控制，一般设为 CPU 核心数；超过 8 核时按公式自动计算，无需硬调
- 不建议强行压低 -XX:MaxGCPauseMillis，否则会缩小年轻代，导致 GC 更频繁，反而拉低吞吐
老年代用 Parallel Old：并行标记-整理，抗碎片
Parallel Old 是 Parallel Scavenge 的老年代搭档，采用多线程并行的标记-整理算法。先并发标记存活对象，再将它们向内存一端压缩，最后清理边界外空间。这样既避免了内存碎片，又支持大对象连续分配，比串行 Serial Old 效率高得多。
- 通过 -XX:+UseParallelOldGC 启用（JDK 8 默认配套开启）
- 所有阶段均为 Stop-The-World，但因并行执行，在 4–8GB 堆规模下 STW 时间仍相对可控
- 不适合堆过大（如 >16GB）或延迟敏感场景——一次 Full GC 可能持续数百毫秒甚至秒级
吞吐量靠参数直接调控，不是靠猜
吞吐量不是估算值，而是 JVM 主动达成的目标指标。核心控制逻辑基于反馈闭环，而非静态配置。
- -XX:GCTimeRatio=n：设定 GC 时间占比上限为 1/(n+1)，例如 n=99 表示允许 GC 占总时间 ≤1%，其余 99% 给用户代码
- -XX:+UseAdaptiveSizePolicy（默认开启）：JVM 自动调优——动态调整年轻代大小、Survivor 比例、晋升年龄等，无需手动设 -Xmn 或 -SurvivorRatio
- -Xms 与 -Xmx 设为相等：避免运行时堆扩容触发额外 Full GC，保障吞吐稳定性
适用与不适用的边界很明确
这套组合不是万能通用型，它的优势和短板都写在设计目标里。
- 适合：后台定时任务、数据报表生成、ETL 批处理、科学模拟等——可接受秒级暂停，但不能容忍 CPU 长期空转等 GC
- 不适合：Web API、实时风控、消息推送等交互服务——Parallel Old 的 STW 容易引发超时、重试雪崩
- 注意版本：JDK 9 起 G1 成为默认，JDK 15+ 中 Parallel Old 已被移除，新项目应优先评估 G1/ZGC
