停顿时间与吞吐量呈反向制约关系：降停顿需更频繁GC，牺牲吞吐；提吞吐则延长单次停顿。应依业务瓶颈选策——支付等低延迟场景优先控停顿，离线任务重吞吐，网关类用G1平衡；按堆大小选回收器，小堆用Parallel GC，中堆用G1并设MaxGCPauseMillis，大堆考虑ZGC；务必通过jstat、gc.log及gceasy.io验证真实指标。
停顿时间与吞吐量本质是反向制约关系：压低单次停顿，往往要靠更频繁、更细粒度的回收动作，这会增加GC总耗时，拉低吞吐量；反过来，追求高吞吐通常意味着减少GC次数、放大单次工作量，停顿自然变长。选策略不是找“最好”，而是看业务真正不能妥协的是什么。
先明确你的核心瓶颈在哪
不同系统对延迟和吞吐的敏感度差异极大：
- 支付接口、实时推荐、游戏同步：用户感知强，STW 超过 100ms 就可能引发超时或卡顿，必须优先保停顿，接受吞吐略降；
- 离线报表、日志清洗、批量导出：无人实时等待，任务完成越快越好，可容忍单次 GC 停顿达 300–500ms，重点压 GC 总耗时占比；
- 微服务网关或中台API：需兼顾——既要避免突发流量下 GC 拖垮响应，又不能让后台线程长期被 GC 线程抢占，适合用 G1 并设 -XX:MaxGCPauseMillis=200 作为平衡点。
按目标选回收器，别硬套默认值
回收器不是越新越好，关键看是否匹配你的堆规模与目标倾向：
- 堆 ≤ 2GB、吞吐优先 → Parallel GC 更稳，参数简洁：-XX:+UseParallelGC -XX:GCTimeRatio=99（即 GC 时间 ≤1%）；
- 堆 4–16GB、需可控停顿 → G1 是主力选择，启用后务必配 -XX:MaxGCPauseMillis=200，并观察 jstat -gcutil 输出的 YGC/FGC 耗时分布；
- 堆 ≥ 16GB、P99 响应必须 ZGC，但需确认 JDK 版本支持（JDK 11+），且注意 -XX:SoftMaxHeapSize 要设，否则预留空间浪费；
- 避免踩坑：CMS 已在 JDK 14 中移除；Serial 仅适用于嵌入式或极小堆场景，别在生产服务里用。
调参不是调数字，而是控行为模式
比如 -XX:MaxGCPauseMillis=100 不是“保证不超100ms”，而是告诉 G1：“请用更小的回收区域、更频繁的年轻代回收、更多并发线程去逼近这个目标”。实际效果取决于：
- 对象分配速率是否稳定——突增会直接打乱预测；
- 新生代是否够大——太小导致 YGC 频繁，反而抬高平均停顿；
- 是否有大对象直入老年代（如 >512KB 的 byte[]）——触发 Mixed GC 或 Full GC，瞬间破防；
- 是否开启 -XX:+UseStringDeduplication（G1）或 -XX:+UseZGC（ZGC）等针对性优化，减少冗余扫描。
验证必须靠真实数据，不是靠感觉
所有调优结论都要落到可观测指标上：
- 加参数启动：-Xloggc:gc.log -XX:+PrintGCDetails -XX:+PrintGCDateStamps；
- 用 jstat -gcutil
1000 实时看 YGC/FGC 次数、耗时、内存变化趋势； - 上传 gc.log 到 gceasy.io，它能自动算出吞吐量（%）、平均停顿、最长停顿、GC 频率等关键值；
- 对比调优前后同一压测流量下的 P95/P99 接口延迟、CPU 使用率、错误率，才能判断是否真有效。
