吞吐量低主要由gc占用过多cpu时间导致，需通过开启gc日志、jstat监控并计算gct占比（超5%即明显拖累，超10%通常是瓶颈），选用合适回收器（如parallel gc适配批处理、g1兼顾延迟与吞吐），合理配置堆结构（固定xms/xmx、增大新生代、调优survivor区及元空间），避免盲目调参或忽视代码问题。
吞吐量低往往和 GC 占用过多 CPU 时间直接相关。核心思路是减少 GC 频次、缩短每次停顿、避免 Full GC，让 JVM 更多时间运行业务代码。
先确认是不是 GC 导致的吞吐量低
不能凭感觉调参，得看真实数据：
- 加参数开启详细 GC 日志：
-Xlog:gc*:file=/path/to/gc.log:time,uptime,level,tags（JDK9+）或旧版用-XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:gc.log - 用
jstat -gc <pid></pid>实时观察 YGC 次数、FGC 次数、各代使用率变化趋势 - 计算吞吐量：如果
GC 时间 / 总运行时间超过 5%，就已明显拖累吞吐；超过 10%，通常就是瓶颈
选对回收器是前提
不同回收器目标不同，选错再怎么调参也难提升吞吐：
- 批处理、后台计算类应用 → 优先用
-XX:+UseParallelGC（JDK8 默认，吞吐量导向） - 堆大于 4GB 且需兼顾延迟与吞吐 → 用
-XX:+UseG1GC，配合-XX:MaxGCPauseMillis=200控制停顿上限 - JDK11+ 且追求极致吞吐 → 可试
-XX:+UseZGC或-XX:+UseShenandoahGC，停顿极短，间接提升有效运行时间 - CMS 已在 JDK14 中移除，JDK17+ 完全不可用，新项目禁止使用
关键内存参数要配平
光换回收器不够，堆结构不合理会加剧 GC 压力：
-
固定堆大小：设
-Xms4g -Xmx4g（数值按实际需要调整），避免运行中扩容缩容带来的额外开销 -
增大新生代：多数对象朝生暮死，新生代太小会导致频繁 YGC 并提前晋升。例如堆 4g，可设
-Xmn1.5g或用-XX:NewRatio=2（老年代:新生代 = 2:1） -
调优 Survivor 区：用
-XX:SurvivorRatio=8（Eden:S0:S1 = 8:1:1），配合-XX:MaxTenuringThreshold=15控制对象晋升老年代的年龄阈值，防止短命对象误入老年代 -
元空间别漏掉：类加载多的应用容易因元空间不足触发 Full GC，加
-XX:MetaspaceSize=256m -XX:MaxMetaspaceSize=256m
避免常见“帮倒忙”操作
有些看似优化的做法反而降低吞吐：
- 盲目调小
-XX:MaxGCPauseMillis（G1/ZGC）→ 回收器被迫更频繁地运行，总 GC 时间上升 - 把
-Xmx设得过大（如占物理内存 80%）→ 系统内存紧张，引发 swap 或 OOM Killer 干预，吞吐断崖下跌 - 没关掉 GC 日志但写到慢盘 → I/O 阻塞应用线程，尤其高并发下日志写入本身成瓶颈
- 忽略代码层问题：比如循环中反复 new 大对象、缓存无淘汰策略、流未 close 导致堆外内存泄漏 → 再好的 GC 参数也救不了
调参不是一锤定音的事，每次改完至少压测 15 分钟以上，对比吞吐量、GC 时间占比、P99 响应时间三个指标是否同步改善。不复杂但容易忽略。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
