JVM 内存调优：到底在调什么？怎么调？

JVM 内存调优：到底在调什么？怎么调？

一、调的是什么？—— 四层结构，层层递进

很多人以为“调优 = 调 -Xmx”，这是最表层的理解。

真正完整的调优包含四层：

二、为什么要调？—— 不调的四种典型死法

死法 1：新生代太小 → Minor GC 频繁 + CPU 飙高

-Xms4g -Xmx4g -Xmn512m  # 新生代仅 512M

→ Eden 秒满，每秒多次 Minor GC；
→ 虽单次快，但累积 STW 时间长，CPU 被 GC 线程吃满；
→ Survivor 放不下存活对象，大量短命对象提前晋升老年代。

死法 2：老年代太小 → Full GC 频繁 + 服务卡顿

-Xmn3g -Xmx4g  # 老年代只剩 1G

→ 缓存、连接池、大对象稍多就撑满；
→ Full GC 触发，STW 1~5 秒，用户请求超时；
→ 如果用 CMS，还会触发 Concurrent Mode Failure，更卡。

死法 3：晋升太快 → 老年代被“垃圾”污染

-XX:MaxTenuringThreshold=1  # 活一次就进老年代

→ 本该在新生代死的对象，全跑老年代去了；
→ Full GC 时要扫描/移动这些“垃圾”，效率极低；
→ Full GC 时间变长，频率变高。

死法 4：选错 GC 算法 → 业务需求与 GC 行为错配

关键纠正：

算法思想相同，但“执行引擎”不同 —— 这才是核心差异。

不调优 = 让 JVM 用“猜的策略”硬扛你的业务 → 轻则性能差，重则 OOM 崩溃。

三、怎么调？—— 四步闭环，从监控到验证

第一步：看监控 —— 找出瓶颈在哪

必须监控的核心指标：

示例 jstat：

S0C    S1C    S0U    S1U      EC       EU        OC         OU       YGC     YGCT    FGC    FGCT
10752.0 10752.0  0.0   8960.0 65536.0  65536.0  175104.0   174890.1   123    2.452   5      8.732

→ EU 满 → 触发 YGC；OU 接近 OC → 危险，快 Full GC。

第二步：调结构 —— 根据对象生命周期调整空间

原则：

• 短命对象多（Web 请求、临时计算）→ 扩大新生代

  -Xmn2g  # 总堆 4G 时，新生代占一半
  

• 长命对象多（缓存、静态数据）→ 扩大老年代

  -XX:NewRatio=3  # 老年代 : 新生代 = 3:1
  

• 对象“中等寿命”（几秒~几分钟）→ 调大 Survivor，增加熬代次数

  -XX:SurvivorRatio=6     # Eden:S0:S1 = 6:1:1 （默认 8:1:1）
  -XX:MaxTenuringThreshold=20  # 默认 15，可适当调高
  

第三步：选算法 + 设目标 —— 匹配业务需求

第四步：验效果 —— 必须对比调优前后数据

调完必须验证：

• Minor GC 次数是否下降？耗时是否缩短？
• Full GC 是否减少 or 消失？
• 平均/P99 响应时间是否改善？
• 吞吐量（TPS/QPS）是否提升？
• 是否出现新问题（如晋升失败、Concurrent Mode Failure）？

工具：

• jstat -gcutil <pid> 1000：实时看 GC 利用率；
• jmap -histo:live <pid>：看存活对象类型分布；
• GC 日志分析（GCeasy / gceasy.io）：可视化对比，看回收率、停顿分布。

开启 GC 日志（必备）：

-Xloggc:/logs/gc.log
-XX:+PrintGCDetails
-XX:+PrintGCDateStamps
-XX:+PrintGCApplicationStoppedTime
-XX:+PrintTenuringDistribution  # 看对象年龄分布，关键！

四、避坑指南：五大高频错误调法