吞吐量与响应时间本质矛盾，需依业务选回收器并调参：parallel gc重吞吐、g1重停顿控制、zgc/shenandoah重超低延迟；-xx:maxgcpausemillis是g1/zgc关键杠杆，推荐起始值200ms，结合gc日志中耗时占比、最大停顿、频率三指标调优。
吞吐量和响应时间本质上是一对矛盾目标，没法同时拉满，只能按应用类型做取舍——批处理类服务优先保吞吐量，交互类服务必须压低单次停顿。关键不是“平衡”，而是根据业务特征选对回收器、设对参数、再微调。
先看清楚三类主流回收器的定位
不同回收器的设计哲学直接决定了它的倾向性：
- Parallel GC（吞吐量优先）：多线程并行回收，但每次GC都STW。适合后台计算、定时任务等能容忍几百毫秒停顿的场景。默认JDK 8+中启用，目标是让单位时间里用户代码运行占比最高。
- CMS（已弃用）/G1（响应时间优先）：G1通过分Region、预测停顿、混合回收，把大停顿拆成多个小停顿。它接受-XX:MaxGCPauseMillis作为软目标（比如200ms），但会为此牺牲吞吐量——堆越小、年轻代越小、GC越频繁。
- ZGC/Shenandoah（超低延迟）：几乎全程并发，单次STW控制在10ms以内，适合金融交易、实时风控等毫秒级敏感系统。代价是额外内存开销和略微降低的吞吐量。
用好 -XX:MaxGCPauseMillis 这个杠杆
这个参数只对G1、ZGC等现代回收器生效，它不是硬上限，而是一个调度信号：
JavaStoryDevelop
下载
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- 设太小（如50ms）→ JVM被迫频繁回收、缩小年轻代、增加GC次数 → 吞吐量明显下滑；
- 设太大（如500ms）→ 单次停顿长，用户体验差，尤其对Web接口或RPC调用不友好；
- 推荐起点：200ms。上线后观察GC日志里的Pause time分布和GC frequency，再逐步收紧或放宽。
别忽略堆结构本身的调节
回收器行为高度依赖堆配置，光调参数没用：
- 年轻代大小直接影响Minor GC频率和单次耗时。G1会自动调整，但可加-XX:G1NewSizePercent和-XX:G1MaxNewSizePercent限制范围；
- 总堆过大（如32G+）却不配ZGC/G1，容易触发长时间Full GC；
- 大对象（>Region一半）会直接进Humongous区，可能引发碎片和意外Full GC，必要时调大-XX:G1HeapRegionSize。
真实调优得靠数据说话
关掉“凭感觉”，打开GC日志看三项核心指标：
- GC总耗时占比：超过10%说明吞吐量已受损；
- 单次最大停顿：是否突破SLA（比如接口P99要求
- GC频次突增：可能是内存泄漏，也可能是MaxGCPauseMillis设得太激进。
用-Xlog:gc*:file=gc.log:time,tags,level（JDK 11+）采集，再用GCViewer或GCEasy分析趋势。
