说实话，面试官问出这个问题的时候，我心里其实是咯噔一下的。毕竟线上服务OOM这种事，对于任何一个后端开发或者运维来说简直就是噩梦的代名词。尤其是像猿辅导这种高并发、大流量的互联网大厂，一旦服务挂了那不仅是技术问题，geng是生产事故。所以这不仅仅是在考你知不知道几个命令，geng是在考你面对突发故障时的思路清不清晰，手稳不稳。

咱们今天就抛开那些枯燥的教科书式定义，来点实战干货。当你的线上服务突然“罢工”，或者监控报警狂响的时候，你到底该怎么一步步把那个隐藏极深的“凶手”揪出来？这篇文章我会把常见的几种OOM场景，以及对应的排查思路和修复手段，像剥洋葱一样一层层讲清楚。

第一步：别急着重启，先搞清楚“死因”

hen多新手kan到服务挂了第一反应就是“赶紧重启恢复服务”。这没错，是止损的第一步，但Ru果你只顾着重启，不保留现场，那下次它还会在同一个地方坑你。所以在重启之前，或者说在平时我们就得有一套完整的“取证”机制。

你得搞明白，这次OOM到底是谁报的？是JVM自己抛的异常，还是操作系统直接把进程给“物理超度”了？这两者完全是两码事，排查方向天差地别。

判定方法：kan日志、kan事件、kan系统

怎么判断呢？其实hen简单，别被那一堆报错吓住。

1. kan应用日志： Ru果你在日志里kan到了 java.lang.OutOfMemoryError 开头的异常，那恭喜你，这是JVM内部的问题。后面跟着的提示词非常关键，比如 Java heap spaceMetaspace 还是 Direct buffer memory。这就像医生kan病，症状Yi经写在脸上了。

2. kan容器事件： 现在的服务基本dou跑在Docker或者K8s里。Ru果你发现日志里啥dou没有，服务突然就没了去执行一下 kubectl describe pod。Ru果你kan到 OOMKilled 这个字眼，并且退出码是137，那这就不是JVMNeng控制的了这是操作系统层面的杀手——因为你的容器内存超限了被K8s给斩立决了。

3. kan系统日志： 在宿主机上敲个 dmesg 或者 tail -f /var/log/messages。Ru果里面出现 Out of memory: Kill process 之类的字眼，那也是系统层面的OOM。这时候JVM可Neng连个遗言dou没来得及留。

场景一：Java堆内存溢出

这是Zui常见的一种，也是大家Zui熟悉的。通常的表现就是堆内存占用持续飙升，Full GC变得异常频繁，Zui后CPU被GC线程占满，应用卡死，或者直接抛出 Java heap space。

定位思路：Dump文件是关键

遇到这种情况，光kan代码是没用的，你得kan内存里到底存了啥。这时候就需要把堆内存导出来也就是Dump。

拿到Dump文件后用MAT或者VisualVM打开。别被那一堆对象kan晕了直接kan Dominator Tree。这里会列出占用内存Zui大的几个对象。点进去，kan GC Roots 路径，这Neng告诉你是谁在引用这些大对象，导致它们无法被回收。

通常你会发现，要么是某个巨大的缓存没设置过期时间，要么是一次性查询数据库加载了太多数据，要么就是内存泄漏。

快速止血与修复

Ru果线上正在发生，为了先活下来：

降级： 赶紧把那些非核心的、消耗大内存的功Neng关掉。比如大文件导出、复杂的批量聚合计算。把批量处理的大小调小，别让流量把内存打爆。

扩容： Ru果是流量实在太大，那就得加机器，或者把堆内存上限调高。但这只是治标，治本还得改代码。

场景二：元空间溢出

Ru果你在日志里kan到了 OutOfMemoryError: Metaspace，那问题通常出在“类”身上。Metaspace主要存的是类的元数据。

根因分析：类加载器泄漏

这种情况Zui常见的原因就是类加载器泄漏。什么意思呢？就是你动态生成了一些类，或者用了热加载、动态代理技术，但是用完之后加载这些类的类加载器没有被回收。

比如你用了Tomcat，但在应用里反复创建和销毁Context，或者用了某些反射框架动态生成代理类却不Zuo清理。这些类在Metaspace里越积越多，Zui后就把空间填满了。

排查与修复

这时候你Ke以开启NMT，用 VM.native_memory summary 命令kankanMetaspace的详细使用情况。

修复起来就比较麻烦了得检查代码里有没有反复创建 URLClassLoader 却没关闭的情况，或者那些动态代理生成的类是不是真的有必要一直存在。临时措施嘛，只Neng是把 -XX:MaxMetaspaceSize 调大一点，或者重启服务释放一下空间。

场景三：直接内存溢出

这个坑比较隐蔽，也是面试官Zui喜欢挖的深坑。症状通常是：JVM的堆内存占用并不高，甚至只有百分之几十，但是服务进程的RSS却高得吓人，Zui后报 Direct buffer memory 错误，或者直接被系统OOM Kill。

罪魁祸首：NIO与Netty

这通常是用了NIO或者Netty这类框架导致的。为了提高IO性Neng，它们会使用堆外内存，也就是Direct ByteBuffer。这部分内存不受JVM堆的限制，直接向操作系统申请。Ru果你用了Netty的 PooledArena，或者某些高性Neng的RPC框架，一旦堆外内存用超了JVM就会报这个错。

定位手段

怎么定位？这时候普通的Dump可Nengkan不出什么。你得用 -XX:MaxDirectMemorySize 来限制一下堆外内存，或者开启NMT查kan Component: Internal 和 Component: Arena 的使用情况。Ru果是Netty应用，Ke以kankan它的指标监控，关注 PooledArena 的使用率。

修复策略

Ru果是参数没配好，显式设置 -XX:MaxDirectMemorySize 调参兜底。Ru果是代码层面的问题，检查一下有没有显式分配堆外内存却没释放的代码，或者限制一下并发连接数，别让瞬间流量把堆外内存冲垮。

场景四：线程数爆表

有时候报错不是内存不够，而是 unable to create new native thread。这其实也是一种变相的资源耗尽。

根因：线程池没设上限或系统限制太低

这通常是因为你的代码里创建了太多线程，比如线程池的队列设得太大，拒绝策略设得不合理，导致任务一多就疯狂创建新线程。或者是系统的 ulimit -u 设置得太低，限制了用户Neng创建的Zui大进程/线程数。

每个线程dou需要占用一定的栈空间，线程多了内存自然也就不够用了。

修复

赶紧kan下系统的 ulimit -a，把 max user processes 调大。代码层面严格限制线程池的Zui大线程数，别让它无限制地增长。

场景五：容器OOMKilled

Zui后说说云原生环境下的特有问题。你发现Pod被杀了JVM连个Dumpdou没留下这就是典型的容器OOM。

误区：Xmx等于容器Limit

hen多同学配置容器资源时把容器内存Limit设为4G，JVM的 -Xmx 也设为4G。这大错特错！JVM的堆只是进程内存的一部分，除了堆，还有Metaspace、线程栈、直接内存、代码缓存、GC本身开销等等。

Ru果 Xmx 等于容器Limit，一旦堆外内存稍微涨一点，总内存就会超限，然后K8s就会毫不留情地把你杀掉。这时候JVM觉得自己还没满呢，就被“物理超度”了。

修复建议

留余量： 这是一个铁律。容器的 memoryLimit 一定要大于 -Xmx。一般建议给堆外内存留出20%~30%的余量。比如Limit是4G，那 -Xmx Zui好设置在2.5G到3G左右。

调参兜底： 显式设置 -XX:MaxMetaspaceSize 和 -XX:MaxDirectMemorySize，别让它们无限增长，把总内存吃光。

工程化治理：防患于未然

聊完了排查，Zui后得说说怎么预防。总不Neng每次dou像救火队员一样到处灭火吧？

JVM启动参数 得配好。这不仅仅是设个 -Xms 和 -Xmx 的事儿。加上 -XX:+HeapDumpOnOutOfMemoryError 和 -XX:HeapDumpPath，让JVM在OOM时自动Dump，这是Zui后的救命稻草。开启 -XX:NativeMemoryTracking=summary 虽然有性Neng损耗，但在排查疑难杂症时它的价值无可替代。

监控 要到位。别光kanJVM的堆内存，还得kan容器的RSS。Ru果RSS持续上升而堆内存hen稳，那大概率就是堆外内存泄漏了。

Zui后降级与限流 是Zui后的防线。当流量洪峰过来或者依赖的服务挂了导致请求堆积时线程池和队列会迅速膨胀。这时候，快速限流、降级非核心业务，是保住服务不被OOM打垮的Zui有效手段。

线上OOM排查，其实就是一场与时间赛跑的侦探游戏。从区分是JVM OOM还是系统OOM，到定位是堆、元空间还是堆外内存，每一步dou需要冷静的判断和扎实的工具使用Neng力。别指望一招鲜吃遍天不同的症状需要不同的药方。希望这篇文章Neng帮你在下次面对“猿辅导二面”这种级别的拷问，或者真实的线上故障时Neng多一份从容，少一份慌乱。

---