Parallel GC的核心价值是提升吞吐量而非降低延迟，它通过多线程并行执行STW阶段的标记、复制、整理任务来压缩单次GC耗时，从而提高应用运行时间占比；默认启用自适应策略，年轻代用Parallel Scavenge（复制算法），老年代用Parallel Old（标记-整理算法），关键参数-XX:GCTimeRatio=99锚定1% GC时间上限，需固定堆大小（-Xms=-Xmx）并依赖GC日志验证实际效果。
Parallel GC 的核心价值是提升系统吞吐量，不是降低单次响应延迟。它通过多线程并行执行 Stop-The-World 阶段任务，在单位时间内压缩 GC 总耗时，从而让应用线程运行时间占比更高。这种设计天然适合“可接受短暂停顿、但必须完成更多工作”的场景。
吞吐量优先的底层逻辑
吞吐量 = 应用运行时间 /（应用运行时间 + GC 时间）。Parallel GC 不减少 GC 次数，而是靠缩短单次 GC 耗时来抬高这个比值。它在 STW 期间启用多个 GC 线程同步完成标记、复制、整理——这意味着 CPU 核心越多，单次停顿越短，整体吞吐越稳。
- 年轻代用 Parallel Scavenge（复制算法），老年代用 Parallel Old（标记-整理算法）
- 默认开启自适应策略（-XX:+UseAdaptiveSizePolicy），自动调优年轻代大小、晋升阈值等
- GC 线程数默认等于物理 CPU 核数；核数＞8 时按 3 + (5×核数)/8 计算，避免调度开销
关键参数如何锚定吞吐目标
真正控制吞吐表现的不是堆大小或新生代比例，而是 -XX:GCTimeRatio。它定义了 GC 时间占总运行时间的上限比例。
- 设为 -XX:GCTimeRatio=99，表示允许 GC 最多占用 1% 时间（1/(1+99)），这是默认值，也是吞吐优先的合理起点
- 不建议调低该值（如设成 19），否则 GC 时间占比升至 5%，反而牺牲吞吐
- 禁用 -XX:MaxGCPauseMillis：它会迫使 JVM 频繁触发小规模回收，打乱自适应节奏，拉低整体效率
硬件与配置必须匹配
Parallel GC 的优势只在合适环境下兑现。脱离实际硬件和业务特征硬套参数，容易适得其反。
- 堆大小必须固定：-Xms = -Xmx（如 -Xms4g -Xmx4g），否则动态扩容干扰自适应建模
- 年轻代不要硬编码：删掉 -Xmn，改用 -XX:NewRatio=2 让 JVM 按比例分配
- 大堆（＞8GB）且多核（≥8）时，可显式设 -XX:ParallelGCThreads 为物理核数的 5/8，缓解线程争抢
什么情况下它会拖慢响应
Parallel GC 不适合对 P99 响应有硬性要求的服务。它的 STW 是全暂停、无并发阶段的，一旦对象生命周期异常，就可能引发连锁反应。
- 缓存膨胀或大对象直入老年代 → 触发 Parallel Old 全堆标记-整理 → 出现秒级 Full GC
- 高并发变量分配速率下，自适应策略可能持续收缩年轻代 → Minor GC 频次飙升 → 应用线程频繁被中断
- 混用 CMS/G1 参数（如 -XX:+UseConcMarkSweepGC）会导致日志中出现 ParNew 而非 PSYoungGen，实际未生效
验证是否真有效
参数写了不等于起效。唯一判断依据是 GC 日志中的真实数据分布。
- 加参数：-XX:+PrintGCDetails -Xlog:gc*:file=gc.log
- 确认日志开头有 Using Parallel GC，且回收器标识为 PSYoungGen 和 ParOldGen
- 统计一段时间内 GC 总耗时占比，应接近 1/(1+GCTimeRatio)；若偏差大，说明对象分配模式异常，需查业务逻辑而非调 GC
- 观察每次 Young GC 后 PSYoungGen used 是否持续高位——这提示存活对象过多，年轻代已调至上限
