吞吐量与延迟本质互斥，需依业务取舍：后台任务重吞吐，实时业务保延迟；parallel gc偏吞吐，g1平衡，zgc/shenandoah主低延迟；调参比换收集器更关键，须结合gc日志验证。
吞吐量和延迟本质上是互斥目标，没法同时拉满，只能按业务真实需求做取舍——不是技术上能不能，而是业务上该不该。
先看业务到底要什么
如果系统跑的是定时报表、日志清洗、模型训练这类任务，用户不盯着界面等结果，重点是“单位时间干完多少活”，那就优先吞吐量；如果处理的是支付请求、实时风控或在线游戏状态同步，用户对卡顿极度敏感，一次 300ms 的停顿就可能丢订单，那就必须保延迟。
- 吞吐量高 ≠ 系统快，而是 GC 占用时间少，比如 99% 的时间都在跑你的代码
- 延迟低 ≠ 不停顿，而是单次 STW 尽量短且可预测，比如 P99 停顿压在 150ms 内
- 两者冲突时，JVM 不会自动妥协——你选 Parallel GC，它就拼命提吞吐，不管停顿多长；你设 G1 的 -XX:MaxGCPauseMillis=200，它就频繁回收，吞吐自然下来
主流收集器的实际倾向
别只看名字，要看默认行为和参数响应：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- Parallel GC：吞吐量优先的标杆。启用 -XX:+UseParallelGC 后，它用多线程并行清扫，但全程 STW。适合堆中等（4–16GB）、能接受 200–800ms 暂停的后台服务
- G1 GC：JDK 9+ 默认，走中间路线。靠 Region 划分和预测模型，在延迟可控前提下尽量不伤吞吐。设 -XX:MaxGCPauseMillis=200 是常见起点，但别设太低（如 50ms），否则反而触发更多 Mixed GC，吞吐反降
- ZGC / Shenandoah：真正为低延迟设计。STW 控制在 10ms 以内，支持超大堆（≥64GB），但需要 JDK 11+（ZGC）或 JDK 12+（Shenandoah），且对 CPU 资源有额外消耗
调参比换收集器更见效
很多时候问题不在收集器本身，而在参数没对齐业务节奏：
- 新生代太小 → Minor GC 频繁，CPU 白耗在回收上；太大 → 晋升加速，老年代压力陡增。建议用 -Xmn 固定大小，或 G1 下用 -XX:G1NewSizePercent=30
- 对象过早进老年代？检查 -XX:MaxTenuringThreshold，默认 15 太保守，多数短命对象 3–6 次 GC 后就该淘汰了
- 大对象直接绕过新生代？加 -XX:PretenureSizeThreshold=1M（按需调整），避免复制开销和 Survivor 区碎片
- 容器环境别硬写 -Xmx4g，改用 -XX:MaxRAMPercentage=70，防 OOMKilled
验证必须靠真实数据
所有判断都要落在 GC 日志上，不能靠感觉：
- 开启日志：-Xlog:gc*:file=gc.log:time,tags,level（JDK 9+）或 -XX:+PrintGCDetails -XX:+PrintGCTimeStamps（旧版）
- 关注三个数字：单次最大停顿（尤其 Full GC）、P95 停顿、GC 时间占总运行时间比例（即吞吐量）
- 工具推荐：GCViewer 快速出报告，JFR（Java Flight Recorder）可关联业务请求做根因分析
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
