吞吐量与响应时间本质互斥，调优需依业务场景权衡：web api等重低延迟（maxgcpausemillis=150～200ms），批处理重高吞吐（可设400～500ms），实时流处理需zgc/shenandoah实现≤10ms稳定停顿。
吞吐量和响应时间在 JVM 垃圾回收中本质互斥，权衡不是“选哪个”，而是看业务真正卡在哪——是总任务跑得慢，还是某次请求突然卡住。
先分清你的系统属于哪一类
不同业务对 GC 表现的容忍边界完全不同：
- Web API、支付网关、实时风控：用户等不了。单次停顿超 200ms 就可能触发重试或超时，P99 停顿必须可控。这类系统响应时间是硬指标，吞吐可适当让步。
- 日终对账、报表生成、ETL 批处理：没人盯着进度条，但要一小时内跑完 100 万笔。允许单次 GC 停顿 400–500ms，只要整体耗时短、CPU 利用率高，吞吐就是第一优先级。
- 流式计算、高频交易引擎：既要快又要稳。不能接受抖动，P99 停顿需压到 10ms 内，且分布极集中。这时普通 G1 都不够，得上 ZGC 或 Shenandoah。
收集器选错，调参全白费
参数再细，也改不了收集器的底层设计目标：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- Parallel GC（吞吐量收集器）：全程 STW，但并行效率高、无协调开销。适合批处理。它不响应 -XX:MaxGCPauseMillis，设了也没用。
- G1 GC（默认推荐）：支持软实时目标，-XX:MaxGCPauseMillis=200 对它有效，能动态调整年轻代大小和回收 Region 数量。适合大多数在线服务，兼顾吞吐与延迟。
- ZGC / Shenandoah：JDK 11+/12+ 起可用，STW 稳定在 10ms 内，堆大小影响极小。但要求 Linux 64-bit，且对元空间、大对象分配敏感，不适合所有生产环境。
调参围绕目标做减法，不是堆参数
明确主目标后，关键参数要克制：
- 要吞吐：增大堆（-Xmx8g）、提高新生代占比（-XX:NewRatio=2）、关注 GCT/Uptime 是否低于 1%；
- 要响应：设合理停顿目标（G1 推荐 200–300ms，别盲目压到 50ms）、避免老年代水位长期 >70%、监控 Humongous 分配频率；
- 共通原则：固定堆大小（-Xms=Xmx），禁用动态伸缩；开启详细 GC 日志（-Xlog:gc*:file=gc.log），用 P95/P99 停顿代替平均值判断。
验证必须靠真实负载，不是单点压测
GC 行为高度依赖实际流量模式：
- 用 APM 工具（如 SkyWalking）把慢请求时间戳和 GC 日志对齐，确认是否真由 GC 引发；
- 对比相同 QPS 下，Parallel 和 G1 的平均响应时间与 P99 延迟变化；
- 观察 Eden 区每秒分配速率（jstat -gc pid 1000），若持续 >50MB/s，说明对象创建压力大，光调 GC 不解决问题，得查代码层缓存、日志、序列化逻辑。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
