oom本质是jvm某内存区域耗尽且gc无法回收，被迫抛出outofmemoryerror；按堆、元空间、直接内存、栈四大区域，成因、分析路径与调优手段各不相同。
Java 应用发生 OOM，本质是某块 JVM 内存区域耗尽且无法回收，JVM 被迫中止分配并抛出 OutOfMemoryError。不同区域的 OOM 表现不同、成因明确、分析路径清晰、调优手段也各具针对性。下面按堆、元空间、直接内存、栈四个核心区域分别说明。
堆内存溢出（java.lang.OutOfMemoryError: Java heap space）
堆是对象实例的主要存放区，也是 GC 管理的核心。溢出最常见，通常表现为应用运行一段时间后突然卡顿、Full GC 频繁、最终崩溃。
- 典型成因：对象持续创建未释放（如静态集合缓存、ThreadLocal 持有引用）、内存泄漏（File/Socket/Connection 未 close）、大数组或大集合一次性加载、年轻代过小导致对象频繁晋升至老年代
-
Dump 分析关键点：启用
-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/dumps/；用 MAT 打开 hprof 文件，查看 Dominator Tree，重点关注占用 Top 的类及其 GC Roots 路径；检查是否有异常增长的集合、未关闭的资源类、重复加载的 classloader 实例 -
调优方向：确认是泄漏还是容量不足——若 dump 中存在大量本该被回收的对象，优先修复代码；若对象合理但总量大，可适当增大堆（
-Xms4g -Xmx4g），同时调整年轻代比例（-XX:NewRatio=2）或 Survivor 区大小，避免过早晋升
元空间溢出（java.lang.OutOfMemoryError: Metaspace）
元空间替代了 JDK 8 以前的永久代，存放类的元数据（类名、字段、方法、常量池等）。溢出不反映在堆内，因此堆 dump 很小却报 OOM，容易误判。
- 典型成因：动态代理类爆炸式生成（CGLIB、ASM、Spring AOP 配置不当）、热部署未清理旧 classloader、大量 JSP 编译、自定义类加载器反复加载同一类但未卸载
-
Dump 分析关键点：堆 dump 对元空间帮助有限，需配合
jstat -gc <pid></pid>观察 MCM/MCU（Metaspace Capacity/Used）增长趋势；用jcmd <pid> VM.native_memory summary scale=MB</pid>查看本地内存中 metaspace 占用；必要时加-XX:NativeMemoryTracking=detail追踪 -
调优方向：设置合理上限（
-XX:MetaspaceSize=256m -XX:MaxMetaspaceSize=512m）防止无节制扩张；排查代理类生成逻辑，禁用 CGLIB 的setUseCache(false)；确保热部署场景下旧 classloader 能被回收；重启应用可临时缓解（避免类重复加载）
直接内存溢出（java.lang.OutOfMemoryError: Direct buffer memory）
直接内存由 JVM 外部管理（如操作系统 malloc），不受堆大小限制，但受 -XX:MaxDirectMemorySize 或系统物理内存约束。NIO、Netty、RocketMQ 等高频使用 direct buffer 的框架易触发此问题。
-
典型成因：ByteBuffer.allocateDirect() 调用过多且未显式 clean（如未调用
buffer.clear()或未释放 Cleaner 引用）、Netty 中 ByteBuf 泄漏、堆外内存池配置过大或未回收 -
Dump 分析关键点：堆 dump 几乎为空或仅含少量 DirectByteBuffer 对象；用
jstat -gc <pid></pid>观察 CCU（Compressed Class Space Used）和 MCU 无明显变化；更有效的是jcmd <pid> VM.native_memory detail</pid>，重点关注 “Internal” 和 “Direct Memory” 分区；Linux 下可用pmap -x <pid></pid>查看进程总 RSS 是否异常飙升 -
调优方向：显式限制直接内存上限（
-XX:MaxDirectMemorySize=1g）；检查 NIO 使用是否遗漏cleaner.clean()或buffer.clear()；Netty 应用开启-Dio.netty.leakDetectionLevel=paranoid定位泄露点；避免在循环中反复 allocateDirect
栈相关异常（StackOverflowError / OutOfMemoryError: unable to create new native thread）
栈分两类问题：单线程深度递归导致 StackOverflowError；线程数超限导致 unable to create new native thread。后者虽带 OOM 字样，实为操作系统级资源耗尽。
- 典型成因：无限递归、过深调用链（如 JSON 反序列化深层嵌套对象）；线程池无界创建、HTTP 连接未复用、Tomcat maxThreads 设置过高、系统 ulimit -u 限制太小
-
Dump 分析关键点：StackOverflowError 会输出完整异常栈，直接定位递归入口；“unable to create new native thread” 需结合
ps -eLf | grep <pid> | wc -l</pid>查当前线程数，对比ulimit -u值；jstack 输出可观察线程状态（大量 WAITING 或 BLOCKED 可能暗示线程池阻塞） -
调优方向：对递归逻辑加深度控制或改用迭代；减小单线程栈大小（
-Xss256k）以容纳更多线程；严格管控线程池（设 core/max size、使用有界队列、配置拒绝策略）；调高系统级线程上限（ulimit -u 65535）；排查连接泄漏（如数据库连接未归还、HTTP client 未 close）
每种 OOM 都对应明确的内存边界与行为特征，抓准现象、配好监控参数、用对分析工具，就能快速收敛根因。调优不是盲目加大内存，而是让资源分配与业务模型匹配。
