半夜十一点，手机一连弹出五六条告警：Full GC 次数超过阈值、老年代占用 98%、接口 RT 持续飙红。打开监控一看，GC 日志里密密麻麻全是连续的老年代回收，每次回收完占用不下来，像一个只进不出的蓄水池。处理这种 JVM 内存区域爆掉的现场，是每个 Java 后端工程师迟早要面对的功课。
这个系列的上篇讲了 JVM 内存区域的划分，堆、栈、元空间、直接内存各自管什么，本篇重点放在另一面：当这些区域装不下了，溢出异常是怎么暴露出来的，用什么思路排查，哪些参数能救急，哪些坑不能踩。内容适合正在做 Java 服务端开发、遇到过 OOM 但不知道从哪儿下手的人，也适合准备面试时想系统梳理一遍 JVM 考点的人。我尽量把这些年踩过的坑和沉淀下来的排查套路揉成能直接用的东西。
1. 先认清四种“溢”的现场
Java 进程报 OutOfMemoryError，实际上是一族异常，不是只有一种。不同内存区域溢出时给的报错关键词完全不一样，排查方向也天差地别。很多人一看到 OOM 就急着加 -Xmx，这个习惯非常危险——如果根本是元空间或直接内存爆了，加堆内存不但没用，还可能掩盖真实问题。
1.1 堆溢出：最常见也最好认的一类
堆溢出的报错是java.lang.OutOfMemoryError: Java heap space，这也是绝大多数 Java 开发者第一次遇到的 OOM。
堆是最容易满的地方，因为几乎所有对象都在这里分配。堆溢出的基本面有两种：一是真的内存泄漏，对象被无意识地持有，垃圾回收不掉；二是对象太多但生命周期本来就不该这么长，比如并发高峰期瞬间产生海量请求对象，属于峰值压力超过了堆容量上限。
有一个很重要的误区需要说清楚：不是所有堆溢出都是泄漏。我见过不少团队一看到 heap space 就怀疑代码里有什么东西没释放，查了一周发现其实是某个大促活动运营配置了错误的容量，请求量翻了十倍，堆就是装不下。所以在定位之前，先确认一句话：这个现象是持续渐进式的，还是突发到达峰值式的？前者倾向泄漏，后者倾向容量规划问题。
写一段最典型的泄漏代码做演示。一个没有覆盖 equals/hashCode 的 Key 类被放进 HashMap，每次请求都 new 一个 Key，永远也找不到已有条目，于是数据只增不减：
public class LeakDemo { private static final Map<Key, Value> CACHE = new HashMap<>(); public static void main(String[] args) throws Exception { for (int i = 0; ; i++) { CACHE.put(new Key(i), new Value(i)); if (i % 1000 == 0) { System.out.println("size = " + CACHE.size()); } TimeUnit.MILLISECONDS.sleep(1); } } static class Key { private final int id; Key(int id) { this.id = id; } // 没有重写 equals() 和 hashCode() } static class Value { private final int data; Value(int data) { this.data = data; } } }跑不了多久就会Java heap space。这个例子放在这里有教学价值：泄漏很多时候不是“忘了赋 null”，而是容器类从逻辑上就留不住应该被回收的东西。
1.2 栈溢出：递归之外还有哪些坑
栈溢出的报错是java.lang.StackOverflowError，注意它是个 Error 而不是 OutOfMemoryError，但本质也是内存区域装不下——准确的说是某个线程的虚拟机栈深度超过了容量上限。
绝大多数人第一反应是“递归太深了”，这没错，但只答对了一半。栈帧大小由两部分决定：局部变量表和操作数栈。一个方法里塞了十几个大数组局部变量，它的栈帧就比空方法大得多，同样的栈容量能压的调用层数就浅得多。所以压栈溢出不一定是递归问题，也可能是一个“方法特别重”的方法在正常业务路径里被反复调用，每次调用栈帧巨大。
栈深度和 -Xss 参数直接相关，这个参数指定每个线程的栈容量。64 位 HotSpot 默认通常是 1MB，如果每个栈帧大约占 1KB～2KB，那么大约能压到几百层上下。真实业务里方法栈帧更大，几百层看起来不小，但框架的调用链很嵌套，例如 MyBatis 映射、Spring AOP 多层代理，再加业务递归，很容易在低配的 -Xss 设置下触顶。
我曾经在排查一个“偶发 StackOverflowError”问题时发现，业务代码里根本没有什么深层递归，倒是在一个工具类里有个方法用 stream 反复 self-call，加上 Spring 代理导致调用链格外长，一压测就挂。把那个方法的 stream 改成简单循环，问题直接消失。栈优化的优先级永远是先减少无谓的调用层级，而不是无脑调大 -Xss。
1.3 元空间溢出：类加载失控的信号
元空间溢出的报错是java.lang.OutOfMemoryError: Metaspace。JDK 8 之后方法区挪到了本地内存，叫 Metaspace。它的特点是：默认没有上限（受物理内存限制），但如果你显式设置了-XX:MaxMetaspaceSize，超过就报这个错。
元空间里存的是类元信息。正常情况下类被加载后，当类加载器和类都不再被引用时，这些元信息可以卸载。但一旦类加载器本身被意外持有，它加载的所有类就都没法回收，元空间使用量就会像爬山一样只涨不跌。
最常见的高发群体是：热部署场景、动态代理大量生成代理类的框架（CGLIB、ByteBuddy）、以及各种 Groovy 脚本、动态 SQL 解析类库。我曾经排查过一个支付系统，每次发布版本都会生成一批 CGLIB 代理类，而项目用了一个自定义的类加载器管理插件。类加载器被静态变量引用没释放，连续发布几次之后 Metaspace 直接爆掉。最后是用jmap -clstats看到了几百个存活类加载器才定位到的。
1.4 直接内存溢出：被遗忘的一块
直接内存溢出的报错是java.lang.OutOfMemoryError: Direct buffer memory。这是 JVM 里最“隐蔽”的一类，因为它在堆外，常规堆 dump 里完全看不到它的占用。
直接内存由-XX:MaxDirectMemorySize控制，默认值约等于堆上限。NIO、Netty 这类库用堆外内存做缓冲区，是为了减少堆内对象拷贝和 GC 压力。代价是：一旦有代码重复申请 DirectByteBuffer 而没有释放，堆内存看起来一点问题没有，Full GC 也不频繁，但进程整体内存占用一路走高，最后 Native 内存不够用。
这类问题排查难度大的原因在于，MAT 分析堆 dump 时看不到问题的核心，你需要在监控里同时看usedDirectMemory这类指标，或者用 JFR（Java Flight Recorder）的 Native Memory Tracking 来辅助。Netty 的缓冲池如果配置不合理，也有可能在无泄漏的情况下高频创建堆外缓冲区，只是生命周期太短导致碎片的堆积。遇到 Direct buffer memory 时，第一反应不应该是“又是谁的 ByteBuffer 没 release”，而是先去看 NMT 报告里 native memory 各分类的走势。
2. 一次真实堆溢出排查的全过程实录
理论讲再多，不如走一遍完整排查。我挑一个典型的堆内存泄漏案例，按实际操作顺序还原过程，包括当时为什么先看 GC 日志，为什么用特定命令，以及每一步得到的判断依据。
2.1 案发现场：GC 日志里面写了什么
那是一个用户积分服务，功能很简单，每天批量对账后更新用户等级。上线后第三周开始告警，特征很明显：每天早上对账跑完后，老年代占用就开始缓慢爬坡，到了晚上也不回落，第二天接着涨。
手里第一份证据是全量 GC 日志。片段大概是这样的：
[Full GC (Allocation Failure) 2.4G->1.8G(2.5G), 3.2130 secs] [Full GC (Allocation Failure) 2.4G->1.9G(2.5G), 3.7150 secs] [Full GC (Ergonomics) 2.5G->1.9G(2.5G), 4.1020 secs]注意一个细节：每次 Full GC 都回收了几百 MB，但回收后老年代占用依然在 1.8G 以上，而且下一次 Full GC 很快又出现。这说明对象不是完全不可达，而是被某种集合长期引用，GC 能清掉一部分临时对象，但核心泄漏对象动不了。
第二个关键观察：告警出现的时间点每天都在同一时段，和业务的对账任务高度吻合。于是思路收敛到：对账任务创建了什么数据，被放到了某个存活周期很长的结构里。
2.2 三板斧：jstat 观察、jmap 抓堆、MAT 定位
第一步用 jstat 看内存池的分配和回收走势：
jstat -gcutil <pid> 1000 10输出里重点看两列：O（老年代占用比例）和FGC（Full GC 次数）。老年代占用百分比随 FGC 次数同步攀升，基本坐实了老年代内存只增不减的判断。
第二步抓堆 dump。这里有个注意事项：jmap -dump会触发 Stop The World，线上服务在高峰期是不能乱抓的。当时选了低峰期执行：
jmap -dump:live,format=b,file=/data/dump/heap-20231012.hprof <pid>加live参数的意思是只 dump 存活对象，文件会小很多，分析时干扰也少。但也要知道，加了live会强制触发一次 Full GC，顺序是：先 GC，再 dump，所以 dump 出来的内容代表“GC 之后还活着的对象”，正好适合找泄漏根源。
第三步把 heap-20231012.hprof 塞进 MAT（Eclipse Memory Analyzer）。分析顺序建议固定：先看Leak Suspects 报告，再进Dominator Tree看大对象持有关系，最后查GC Roots。当时 Leak Suspects 直接给了一个结论：某个 ArrayList 的 Total Heap Size 占到了堆的 68%，Retained Heap 巨大。
顺着 Dominator Tree 一路展开，很快就找到对象持有链：TaskExecutor → 静态 ConcurrentHashMap → ArrayList → 对账明细对象。代码里是一个静态的“最近一次对账结果缓存”，只写不淘汰，每天往里塞十几万条明细，没有任何容量上限。这条链肉眼可见地清晰，不需要任何玄学。
2.3 修复与验证：不是改完参数就结束
当时的修复方案很简单：把静态缓存改成带过期时间的 Caffeine 本地缓存，单 key 存储汇总结构而不是明细列表，并且对内存使用加了监控告警。
但真正值得讲的不是修复本身，而是验证方法。我习惯用三个步骤确认“修透了”：第一，代码修复后重启，观察连续七天的老年代曲线，确认斜率归零；第二，用压测工具把对账数据量拉到线上峰值的两倍，跑完看 Full GC 频率是否回归正常；第三，把 JVM 参数里-XX:+HeapDumpOnOutOfMemoryError打开，万一再溢出，至少能自动留下现场，不用等人工抓取。加了这个参数之后，JVM 在第一次 OOM 时会把堆现场自动 dump 出来并打印文件位置，这对事后追查非常重要。
3. 参数与工具链：先弄懂怎么调，再谈调到多少
很多资料喜欢直接给“标准答案”，比如“堆默认设置成物理内存的一半”。这种说法误导性很强。JVM 参数的作用是约束行为边界，没有一套参数能适配所有业务。我把自己常用到的参数整理成了一份速查表，每个参数的适用场景和注意事项都写在旁边。
3.1 常用 JVM 内存参数速查表
| 参数 | 作用 | 建议与提醒 |
|---|---|---|
-Xms/-Xmx | 堆初始大小 / 堆最大大小 | 生产环境建议设成相同值，避免运行期堆扩容时出现额外停顿 |
-Xss | 单线程栈容量 | 默认 1MB 左右。不要为了省内存粗暴调低到 128k 以下，容易引发栈溢出 |
-XX:MaxMetaspaceSize | 元空间上限 | 必须设。不设等于让元空间挤压本机其他进程的内存 |
-XX:MaxDirectMemorySize | 直接内存上限 | 用了 Netty 就必须关注，默认值等于堆上限，对堆外占用心里要有数 |
-XX:+HeapDumpOnOutOfMemoryError | OOM 时自动 dump 堆 | 强烈建议开启，配合下面的 -XX:HeapDumpPath 指定目录 |
-XX:HeapDumpPath | dump 文件保存路径 | 指向有足够磁盘空间的目录，文件名会自动带 pid |
-XX:+PrintGCDetails | 打印 GC 明细日志 | 老版本 JVM 常用，现在的容器化环境建议改用统一日志参数 |
有一个很多人忽略的点：-Xmx的配置不能只看应用本身。一台机器上跑的还有 GC 线程、JIT 编译器、元空间、直接内存、线程栈，这些全在进程地址空间里。如果堆上限设得几乎等于容器内存上限，那么堆外那些开销会先扛不住。反过来说，若-Xmx设得太小，高峰期对象分配不下去，也会触发频繁 Full GC。合理范围取决于业务对象的存活率，没有统一数值。我的习惯是先压测，再观察监控里的堆占用快照，把-Xmx设在稳定高水位峰的 1.5~2 倍左右，留出峰谷缓冲。
3.2 内存泄露查看工具横向对比
工具选型上，我按处理阶段把它们分成三类：线上快速观测、现场快照抓取、离线深度分析。
| 工具 | 定位 | 优势 | 短板 |
|---|---|---|---|
| jstat | 线上实时观测 | JDK 自带、零安装、命令轻量 | 只有数值，看不到对象明细 |
| jmap | 现场抓取 | dump 堆快照、clstats 看类加载器 | dump 时会 STW，要注意时机 |
| jhat | 离线分析 | JDK 自带，能看对象直方图 | 交互老式、大 dump 吃力，现在用得很少 |
| JConsole / VisualVM | 本地开发观测 | 图形界面直观，适合本机调试 | 线上环境一般不开放 JMX 端口 |
| MAT | 离线深度分析 | Leak Suspects 和 Dominator Tree 极好用 | 对超大 dump 文件内存要求高 |
| Arthas | 线上综合诊断 | dashboard、heapdump、thread 命令都很实用，还能在容器里用 | 生产环境用它需要审慎评估权限管控 |
Alibaba Arthas 里的heapdump命令可以直接导出堆快照，thread -n 3能瞬间看到最忙的三个线程，这两个命令在容器化环境特别香，因为很多云原生环境里根本没有jmap的安装条件。我现在的线上排查习惯是：先用 Arthas 的dashboard看内存池占用与 GC 次数，迅速锁定大致区域，再决定是否需要 dump 做深度分析，而不是一上来就抓 dump。
3.3 一段常用的命令行排查流程
下面这段命令序列是我在 Linux 服务器上排查内存问题时习惯先跑的几条，顺序是经过实际验证的。先确认进程和参数，再看 GC 走势，最后决定是否抓 dump。
# 确认进程与启动参数，重点看 Xmx、Xss、MetaspaceSize ps -ef | grep java jcmd <pid> VM.flags | tr ' ' '\n' | grep -E 'Xmx|Xss|MaxMetaspace|MaxDirect' # 观察 GC 与内存池走势，每 1 秒输出一次，共 10 次 jstat -gcutil <pid> 1000 10 # 查看类加载器统计，定位 Metaspace 泄漏 jmap -clstats <pid> # 抓堆现场（低峰期操作，会触发 Full GC） jmap -dump:live,format=b,file=/data/dump/heap.hprof <pid>这套命令解决不了所有问题，但覆盖了堆、元空间两类最常见的现场。直接内存问题则要看进程的 Native 内存，单靠 jmap 不够，需要开启 NMT（-XX:NativeMemoryTracking=summary），再jcmd <pid> VM.native_memory summary看分类统计。NMT 本身有少量性能开销，线上开启前需要评估。
4. 面试官想听到的：JVM 内存与溢出的关键认知
JVM 相关的面试题，基本绕不开内存区域、GC、溢出异常、调优这几个话题。这里我不去背题，而是把高频考点背后真正需要建立的几个认知讲透。
4.1 内存区域和溢出异常的对应关系
很多面试问题是“每个内存区域都什么时候会溢出”。这张对应关系表可以作为答题骨架：
| 内存区域 | 溢出异常 | 典型触发场景 | 排查入口 |
|---|---|---|---|
| 堆 | Java heap space | 内存泄漏、峰值对象过多 | 堆 dump + MAT |
| 虚拟机栈/本地方法栈 | StackOverflowError | 递归无出口、调用链过深、栈帧过大 | 线程 dump，检查调用栈 |
| 元空间 | Metaspace | 动态生成类、类加载器泄漏 | jmap -clstats统计类加载器 |
| 直接内存 | Direct buffer memory | NIO/Netty 堆外缓冲区泄漏或碎片化 | NMT 或 JFR 的 native memory 走势 |
这个表里有个细节值得展开：为什么栈溢出是 StackOverflowError 而不是 OutOfMemoryError？因为栈空间在创建线程时就已经确定，请求的 depth 超出容量时 JVM 直接认为“栈深度计算错误”，而不是“内存不足”。如果创建线程本身都开不了新栈，那就变成Unable to create new native thread，这类报错实际是操作系统线程资源耗尽，属于另一套排查思路，经常和 ulimit 限制、线程数失控挂钩。
4.2 “内存泄漏”和“内存溢出”到底有什么区别
这个经典考点的标准答法大家都会背：泄漏是对象无法被回收，溢出是真的装不下了。但面试官更想听的是二者之间的因果关系。
打个比方：内存好比一个水桶，水位持续上涨到溢出来，叫溢出。水位上涨的原因有两种可能：桶底有个洞，水一边漏进来一边渗下去，但进水速度大于漏水速度，桶最终还是会满——这是泄漏加高速进水；另一种是桶本身没洞，但水管拧到了最大，冲洗量超过了桶的容量，一样会溢出来——这是纯峰值压力。排查的时候，如果只确认“溢出了”，很难知道是哪种原因。所以正确姿势是先用 GC 日志和堆 dump 判断对象存活情况，如果 GC 后占用仍然很高，倾向泄漏；如果 GC 后占用能大幅下降但很快又满，倾向容量不足。
顺带说一下 JRE 和 JVM 的关系。这个知识点虽然基础，但经常被混在“启动报错”里考。JRE 是 Java 运行时环境，里面包含了 JVM 实现、核心类库和其他运行时组件；JVM 是 JRE 的核心执行引擎。启动 Java 程序时，先通过启动器找到 JRE 里的 JVM，再让 JVM 加载并执行字节码。如果启动器找不到可用的 JVM，就会看到no suitable jvm was found to start the application。这个报错在 Windows 双击打包应用时很常见，多数和 JAVA_HOME 未配置、32 位程序找了 64 位 JRE、或者注册表信息缺失有关，并不是代码层面的问题。
4.3 调优面试题的底层逻辑：先量化，再动手
JVM 调优的面试题经常问“你的 JVM 参数怎么设置的”。如果直接回答“Xmx 设了 4g”，基本暴露了没有体系。面试官真正想看的是你面对一个具体性能问题时，怎么建立判断路径。
我常用的调优路径只有四步：第一，量化现状，通过 GC 日志和监控拿到 Full GC 频率、单次停顿时间、各代占用曲线；第二，定位卡点，是分配速率过高、晋升过快、还是存在泄漏；第三，针对卡点做最小干预，一次只改一个参数；第四，用压测验证并对比调优前后数据。这个闭环比任何具体参数都重要。
举个实际例子：某服务 GC 停顿平均 300ms，但线上 P99 要求低于 200ms。GC 日志显示新生代 Minor GC 频率不算高，但每次进入老年代的对象量很大，导致老年代快速膨胀触发 Full GC。这种情况下，盲目调大堆只能推迟问题，正确的干预方向其实是调整晋升阈值（-XX:MaxTenuringThreshold相关）和 Survivor 区大小，让更多对象在新生代被回收，而不是一股脑往老年代送。调优不是比拼参数调得多花哨，而是比拼你对分配和回收链路的理解。
5. 高频问题速查与避坑经验
最后这部分是我这几年的问题清单，专门挑那些“平时没人写、出了事才发现”的细节。我把它整理成速查表的样式，方便遇到问题时直接对号入座。
5.1 常见问题定位对照表
| 现象 | 可能原因 | 第一排查动作 |
|---|---|---|
| 老年代占用持续上涨，FGC 后不回落 | 堆内对象泄漏 | 抓堆 dump，看 Dominator Tree 的 Retained Heap |
| Minor GC 后大量对象进入老年代，FGC 频繁 | 晋升阈值太小或 Survivor 区不足 | 调整 survivor 比例和晋升阈值，别急着加堆 |
MetaspaceOOM，重启后能恢复 | 类加载器泄漏或动态类生成失控 | jmap -clstats统计存活加载器数量 |
| 进程内存占用远超堆上限 | 直接内存或元空间在堆外增长 | 开启 NMT，看 native memory 分类走势 |
频繁Unable to create new native thread | 线程数超过系统限制 | 查 ulimit、线程池是否无限创建、容器 pid 限制 |
启动时No suitable JVM was found | 启动器找不到 JRE 里的 JVM | 检查 JAVA_HOME、Path、32/64 位匹配 |
5.2 我踩过的几个坑，说出来让你少走弯路
第一个坑是线上抓 dump 的时机。有一次我没看监控直接用jmap -dump:live抓一个高负载服务，本来就快 Full GC 了，再触发一次 GC 加 dump 写盘，服务直接僵住两分钟。从那以后，我抓 dump 前必看当前的 FGC 频率和 CPU 水位，非紧急情况一律低峰期处理。紧急情况也优先用-XX:+HeapDumpOnOutOfMemoryError配合自动 dump，让 OOM 发生时系统自己保留现场。
第二个坑是分析 dump 时把注意力全放在“大对象”上。MAT 的 Histogram 按占用排序，排在最前面的往往是某个基础类型的数组，如果你只盯着它看，可能半天看不出业务问题。正确做法是直接看 GC Roots 的引用链，注意力放在“谁通过什么路径持有了这些数据”。大对象本身不是问题，持有它的那条链才是问题。
第三个坑是元空间溢出时重启就能恢复，导致很多团队一直靠重启续命，直到发布频繁之后彻底没法启动。我当时遇到的那个支付系统就是这样，连续几个版本发布后某台机器直接 Metaspace OOM 起不来。解决思路不是调大-XX:MaxMetaspaceSize，而是找到持有了类加载器的静态引用。这里检查的范围很具体：看有没有自定义 ClassLoader 被放进了缓存、有没有框架动态生成大量代理类、有没有临时目录加载过不常用的 jar。元空间这类问题，重启只能掩盖，不会修复。
第四个坑和命令工具有关：新版 JDK（从 9 开始）已经移除了独立的 jhat 工具，老博客里的 jhat 用法有一部分已经过时。另外jmap -dump里的live参数到底加不加，要分清楚场景——排查泄漏时加live抓存活对象更聚焦，但如果你怀疑的是“堆内存里有很多本应死掉的临时对象没有被回收”，不加live抓全量 dump 反而能看到更多细节。
最后分享一个我自己的小习惯：每次调整内存参数之后，我不只看压测数据，还看连续一周的监控曲线。内存问题有滞后性，压测那十分钟跑得好不代表三天后内存不涨。把老年代占用曲线、FGC 频率、进程 RSS 三条曲线拉出来放一起对比，比任何压测报表都更接近真相。这套“先看区域，再抓现场，最后修根因”的思路，帮我解决过的线上问题不计其数，也希望你在下一次 OOM 告警来临之前已经准备好了。
