提升Java应用吞吐量的核心是降低GC时间占比（超5%即明显拖累），需先通过GC日志和jstat确认瓶颈，再选用Parallel GC（批处理）、G1（兼顾延迟与吞吐）或ZGC/Shenandoah（JDK11+大堆低停顿），配合固定堆大小、合理新生代与Survivor配置，并避免盲目调参和代码层内存泄漏。
提升 Java 应用吞吐量，核心是让 JVM 尽可能多地执行业务代码，而不是花时间做垃圾回收。关键不在于“调参越多越好”，而在于让 GC 频次低、单次耗时短、不触发 Full GC，尤其避免 GC 时间占总运行时间超过 5%。
先确认是不是 GC 拖累了吞吐量
别猜，要测：
- 加参数开启 GC 日志：JDK9+ 用 -Xlog:gc*:file=gc.log:time,uptime,level,tags；旧版用 -XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:gc.log
- 用 jstat -gc <pid> 实时看 YGC/FGC 次数、各代使用率变化
- 算 GCT 占比：GC 总耗时 ÷ 应用总运行时间。超 5% 就已影响明显，超 10% 基本就是瓶颈
选对回收器比调参更重要
回收器目标不同，用错方向再怎么调也白搭：
- 批处理、后台计算类（如定时任务、ETL）→ 用 -XX:+UseParallelGC（JDK8 默认，吞吐量导向）
- 堆 ≥ 4GB，又希望兼顾延迟与吞吐（如微服务、API 网关）→ 用 -XX:+UseG1GC，配合 -XX:MaxGCPauseMillis=200 控制停顿上限
- JDK11+ 且追求极致吞吐+大堆（如数据中台、实时分析）→ 可试 -XX:+UseZGC 或 -XX:+UseShenandoahGC，停顿极短，间接提升有效运行时间
- CMS 已在 JDK14 移除，JDK17+ 不可用，新项目必须避开
堆结构配平才能发挥回收器效能
光换回收器不够，堆大小和比例不合理，反而加重 GC 压力：
立即学习“Java免费学习笔记（深入）”；
- 固定堆大小：-Xms4g -Xmx4g（数值按实际需调整），避免运行中扩容缩容抖动
- 新生代别太小：多数对象朝生暮死，建议占堆 1/3～1/2。例如堆 4g，可设 -Xmn1.5g 或 -XX:NewRatio=2（老:新 = 2:1）
- Survivor 区要够用：-XX:SurvivorRatio=8（Eden:S0:S1 = 8:1:1），若 GC 日志里常出现 “Desired survivor size” 被突破或晋升量突增，说明 Survivor 不足，可调小该值（如设为 4）
- 元空间别漏掉：-XX:MetaspaceSize=256m -XX:MaxMetaspaceSize=256m，防止类加载多引发 Full GC
避开常见“帮倒忙”操作
有些操作看似优化，实则拉低吞吐：
- 盲目压低 -XX:MaxGCPauseMillis（G1/ZGC）→ 回收器被迫更频繁运行，总 GC 时间反升
- 把 -Xmx 设得过大（如占物理内存 80%）→ 触发系统 swap 或 OOM Killer，吞吐断崖下跌
- 开着 GC 日志但写到慢盘 → 高并发下日志 I/O 成瓶颈，阻塞应用线程
- 忽略代码问题：比如循环里 new 大对象、缓存没淘汰策略、流未 close —— 这些比 JVM 参数影响更大
