堆内存调优（上）：-Xms与-Xms设置原则、新生代与老年代比例调优、实战案例：OOM异常分析
堆内存调优，说白了就是给JVM分钱、分地。钱给少了不够花，给多了浪费资源。地分不好，GC频繁，系统卡顿。这一讲，我带你把这笔账算清楚。
一、-Xms 与 -Xmx：堆内存的“地板”和“天花板”
这两个参数是堆内存调优的起点。-Xms 是初始堆大小，-Xmx 是最大堆大小。很多人直接设成一样，图省事。但为什么这么做？有没有例外？
1.1 核心原则：-Xms = -Xmx
我个人习惯，生产环境一律把 -Xms 和 -Xmx 设为相同值。原因很简单：
- 避免性能抖动：JVM在运行时如果发现堆不够用，会向操作系统申请更多内存。这个申请动作是有开销的，而且会触发Full GC来整理空间。你想想看，线上流量高峰期突然来一次扩容GC，系统响应时间直接飙升。
- 内存资源确定性：设成相同值，堆大小从一开始就是最大值。操作系统会一次性分配好虚拟内存，运行时不再动态调整。这对容器化部署尤其重要——你申请了4G，就别让JVM只占2G然后慢慢涨。
一句话总结：-Xms = -Xmx，省心、稳定、可预测。
1.2 设置原则：多大才合适？
堆大小不是越大越好。我见过有人给一个简单的Web服务设了32G堆，结果GC停顿时间超过10秒。为什么？因为堆越大，GC扫描的对象越多，单次停顿时间越长。
这里有个经验公式：
| 应用类型 | 推荐堆大小 | 说明 |
|---|---|---|
| 高并发Web服务 | 4G - 8G | 对象生命周期短，堆太大反而增加GC压力 |
| 批处理/大数据 | 8G - 32G | 需要缓存大量中间数据，但注意GC停顿 |
| 实时/低延迟系统 | 2G - 4G | 宁可频繁Minor GC，也不要长停顿Full GC |
| 微服务/容器化 | 不超过容器内存的70% | 给操作系统和堆外内存留余地 |
避坑指南：我曾经接手过一个项目，堆内存设了16G，但实际活跃对象只有2G。每次Full GC都要扫描16G的堆，停顿时间长达8秒。后来我把堆降到4G，停顿时间降到500ms以内。记住：堆大小不是越大越好，够用就行。
二、新生代与老年代比例调优
堆内存分代管理，新生代放“短命”对象，老年代放“长寿”对象。比例调不好，要么Minor GC频繁，要么对象过早晋升到老年代，引发Full GC。
2.1 默认比例：-XX:NewRatio
-XX:NewRatio 控制新生代和老年代的比例。默认值是2，意思是老年代是新生代的2倍。也就是说，新生代占堆的1/3，老年代占2/3。
但这个默认值适合你的应用吗？不一定。
2.2 调优原则：看对象存活率
我一般这样判断：
- 对象存活率低（大部分对象在Minor GC后就死了）：比如Web请求处理，每次请求创建大量临时对象。这时候应该加大新生代，减少对象晋升到老年代的概率。
- 对象存活率高（对象生命周期长）：比如缓存服务、状态管理。这时候新生代可以小一点，避免频繁的Minor GC做无用功。
具体怎么调？我习惯用 -Xmn 直接指定新生代大小，而不是用比例。比如：
java -Xms4g -Xmx4g -Xmn2g -XX:SurvivorRatio=8 -jar app.jar这个配置的意思是：堆4G，新生代2G，老年代2G。新生代中Eden区占8/10，两个Survivor区各占1/10。
2.3 Survivor区：容易被忽略的细节
Survivor区太小，对象会直接晋升到老年代；太大，浪费空间。默认 -XX:SurvivorRatio=8 通常够用。但如果你发现Minor GC后老年代增长很快，可以检查一下Survivor区是否够用。
小技巧：用 jstat -gcutil <pid> 1000 观察Survivor区的使用率。如果每次Minor GC后Survivor区都快满了，说明空间不够，可以适当调大SurvivorRatio或者增大新生代。
三、实战案例：OOM异常分析
OOM（OutOfMemoryError）是堆内存调优最直接的反馈。遇到OOM，别慌，按步骤来。
3.1 案例背景
一个在线支付服务，运行两周后突然报错：
java.lang.OutOfMemoryError: Java heap space重启后恢复正常，但两周后又出现。典型的“内存泄漏”特征。
3.2 分析步骤
- 加启动参数，保留现场：
-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/path/to/dump.hprof这样OOM时自动生成堆转储文件，方便事后分析。
- 用MAT分析堆转储：
打开dump文件，看 Leak Suspects 报告。MAT会告诉你哪个对象占用了最多内存，以及它的GC Root路径。
- 定位问题：
在这个案例中，我发现一个 HashMap 占用了超过80%的堆内存。key是用户ID，value是一个订单详情对象。但问题是，这个Map只增不减——用户完成支付后，订单详情没有被移除。
- 修复代码：
原来是开发人员用了一个静态Map来缓存订单信息，但忘记在支付完成后清理。改成 WeakHashMap 或者加上定时清理逻辑后，问题解决。
3.3 另一种OOM：GC overhead limit exceeded
还有一种常见的OOM：
java.lang.OutOfMemoryError: GC overhead limit exceeded这个意思是JVM花了超过98%的时间做GC，但回收的内存不到2%。说白了，就是堆太小，GC一直在做无用功。
遇到这种情况，先别急着加堆。检查一下代码里是不是有循环创建大对象、或者频繁加载大文件的操作。我遇到过有人每秒钟加载一次10MB的配置文件，堆设多大都不够用。
核心思路：OOM分析，先看代码，再看配置。代码问题不解决，堆设再大也是治标不治本。
四、知识体系：堆内存调优全景图
下面这张图，帮你把这一讲的核心逻辑串起来：
五、避坑清单
最后，我把这一讲的核心避坑点列出来，你直接拿去用：
| 坑 | 表现 | 解决方案 |
|---|---|---|
| -Xms 远小于 -Xmx | 系统运行一段时间后突然卡顿 | 设成相同值 |
| 堆设得过大 | GC停顿时间过长 | 根据应用类型合理设置，不要超过32G |
| 新生代太小 | 对象频繁晋升到老年代，触发Full GC | 调大 -Xmn 或 -XX:NewRatio |
| Survivor区不足 | Minor GC后对象直接进入老年代 | 调大 -XX:SurvivorRatio |
| OOM时没有保留现场 | 无法定位问题根因 | 加上 -XX:+HeapDumpOnOutOfMemoryError |
最后提醒一句：堆内存调优没有银弹。每个应用都有自己的特点，别照搬别人的配置。多观察、多分析、多验证，才是正道。