parallel scavenge调优核心是保障吞吐量，关键参数为-xx:gctimeratio（如99表示gc≤1%），需开启自适应策略、固定堆大小、禁用冲突参数，并通过gc日志验证实际吞吐达成度。

Parallel Scavenge 收集器的调优核心不是压低单次停顿，而是让 JVM 在长时间运行中把尽可能多的时间留给用户代码。它的“吞吐量优先”体现在目标明确、机制自动、配置简洁——关键在于给对目标、稳住环境、看准日志。

用 -XX:GCTimeRatio 锚定吞吐目标

这是最直接、最有效的调优动作。它告诉 JVM：“GC 总耗时最多占总时间的 1/(N+1)”。

• 设为 -XX:GCTimeRatio=99，即允许 GC 占比 ≤1%（99/100），这是默认值，也适合大多数高吞吐场景
• 若 CPU 资源充足且业务完全不敏感延迟，可设为 199（GC ≤0.5%），JVM 会进一步扩大年轻代、减少 Minor GC 次数
• 避免设得过小（如 19 → GC ≤5%），这会显著牺牲吞吐，背离 Parallel Scavenge 的设计初衷
• 该参数仅在启用 -XX:+UseParallelGC 且自适应策略开启时生效（后者默认已开）

关闭干扰项，信任自适应机制

Parallel Scavenge 的优势恰恰在于它能自己学着调参，而不是靠人手动平衡一堆变量。

deep-java-review

Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...

下载

• 保持 -XX:+UseAdaptiveSizePolicy 开启（默认就是），让 JVM 自动调整年轻代大小、Survivor 比例、对象晋升年龄等
• 不要设置 -XX:MaxGCPauseMillis，尤其不能设得很紧（如 100ms）。它会迫使 JVM 缩小年轻代换短停顿，结果是 GC 更频繁、总耗时上升，吞吐反而下降
• 删掉所有 CMS/G1 相关参数（如 -XX:+UseConcMarkSweepGC），混搭会导致实际启用 ParNew 而非 PSYoungGen，彻底偏离目标

固定堆大小，保障调节稳定性

自适应策略需要稳定的内存基线才能建模和收敛。

• 必须设置 -Xms 和 -Xmx 相等，例如 -Xms4g -Xmx4g，避免运行中扩容触发额外 Full GC，打断吞吐节奏
• 堆总量按应用峰值内存占用设定，留 10%~20% 余量即可；过大不仅浪费，还会拉长单次 Parallel Old STW 时间
• 不要用 -Xmn 硬编码年轻代大小，它会覆盖自适应逻辑；如需倾向更大年轻代，可用 -XX:NewRatio=2（年轻代占堆 1/3）或 =1（占 1/2）

通过 GC 日志验证真实吞吐达成度

参数写对了不等于效果达到了。真正判断调优是否成功，得看长期运行的日志统计。

• 启动时加上 -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -Xloggc:gc.log
• 确认日志开头出现 Using Parallel GC 或 PSYoungGen、ParOldGen 字样，说明组合正确
• 统计数小时内的 GC 总耗时占比，应稳定接近你设定的目标（如 GCTimeRatio=99 → 实际占比 ≈1%）
• 若 Full GC 频繁，不是调参数能解决的，要检查代码：是否存在缓存未清理、大对象直入老年代、或数据结构长期持有中间结果

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南