吞吐量不足的核心原因是gc停顿长、对象分配快、线程阻塞或内存结构不合理；需通过固定堆大小（-xms8g -xmx8g）、合理分代（-xmn3g，-xx:survivorratio=8）、启用g1并设目标停顿（-xx:+useg1gc -xx:maxgcpausemillis=50）、管控元空间与线程栈、配齐gc日志与jfr实现精准调优。
吞吐量不足，核心是单位时间处理请求数上不去，常见原因不是 CPU 不够，而是 GC 停顿太长、对象分配过快、线程阻塞或内存结构不合理。JVM 调优要围绕“减少停顿、加快回收、压低晋升、释放 CPU”四个动作展开，而不是盲目加堆或换 GC 器。
堆结构必须固定且分代合理
动态伸缩堆（-Xms ≠ -Xmx）会导致扩容缩容时 STW，直接拖垮吞吐。高并发服务必须设为固定大小：
- -Xms8g -Xmx8g：单实例建议控制在 4–16GB，超 16GB 会显著拉长 G1/ZGC 的并发标记耗时
- -Xmn3g（或 -XX:NewRatio=2）：新生代占堆 1/3～2/5；若监控发现 YGC 频繁（如每秒 ≥2 次），可适当调高新生代，降低 Minor GC 次数
- -XX:SurvivorRatio=8：确保 Eden 区占比大，Survivor 留足空间容纳幸存对象，避免过早晋升
选对 GC 器并精准调参
吞吐优先 ≠ 用 Parallel GC，要看业务是否允许短暂停顿。大多数 Web/API 服务适合 G1，目标是稳住单次 GC 时间：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- -XX:+UseG1GC：启用 G1，比 CMS 更稳定，比 Parallel 更可控延迟
- -XX:MaxGCPauseMillis=50：设为目标值（非保证值），G1 会据此动态调整 Region 数和并发线程数
- -XX:G1HeapRegionSize=4M：堆 >8GB 时建议设为 2–4MB，减少 Region 数量，缓解碎片与扫描开销
- 避免 ZGC 在吞吐型服务中滥用：ZGC 需要额外 CPU 资源做并发标记/重定位，若 CPU 已近饱和，反而降低吞吐
堵住隐性内存泄漏与无效开销
吞吐瓶颈常藏在元空间、线程栈和逃逸分析失效点：
- -XX:MetaspaceSize=384m -XX:MaxMetaspaceSize=768m：Spring Boot 多模块+热部署场景易撑爆元空间，不设上限会触发 Full GC
- -Xss256k：线程池规模大（如 >500 线程）时，降栈大小可多开几百个线程，同时降低上下文切换内存压力
- -XX:+DoEscapeAnalysis -XX:+EliminateAllocations：默认开启，但需确认未被 -XX:-TieredStopAtLevel=1 等参数禁用；配合 StringBuilder 复用、对象池等代码层优化效果更明显
必须配齐可观测性底座
没日志的调优等于蒙眼开车。仅靠 jstat 或 Prometheus 指标无法定位 GC 毛刺根源：
- -Xlog:gc*,gc+age=trace,safepoint:file=/data/jvm/logs/gc.log:time,tags,level,pid：JDK 11+ 标准格式，记录每次 GC 类型、晋升年龄、STW 时长
- -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/data/jvm/dump/：OOM 时自动抓堆快照，用于分析大对象、集合泄漏、静态引用等
- 配合 JFR（Java Flight Recorder）开启 -XX:+FlightRecorder -XX:StartFlightRecording=duration=60s,filename=/data/jvm/logs/recording.jfr：捕获 GC、锁、线程、方法采样全链路数据
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
