OOM是JVM明确报告某内存区域分配失败，非模糊“内存不够”；常见类型包括堆溢出（Java heap space）、元空间溢出（Metaspace）、线程创建失败（Unable to create new native thread）和直接内存溢出（Direct buffer memory），每种对应特定原因与排查方法。
Java 应用抛出 OutOfMemoryError（OOM），不是“内存不够用”的模糊判断，而是 JVM 明确告诉你：某块内存区域已无法满足当前分配请求。不同报错信息直接对应不同内存区域问题，快速识别是解决的第一步。
堆内存溢出（Java heap space）
这是生产环境最常遇到的 OOM 类型，错误提示明确为 java.lang.OutOfMemoryError: Java heap space。
- 典型诱因是一次性加载过多数据，比如导出全表、缓存全部配置、解析超大 JSON 或 XML 文件；
- 内存泄漏更隐蔽：静态集合长期持有对象引用、监听器未注销、线程局部变量（ThreadLocal）未清理、缓存未设淘汰策略等，导致对象无法回收；
- JVM 堆参数设置过小（如
-Xmx512m）在高并发或大数据量场景下也容易触发。
排查建议：启动时加上 -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/tmp/heap.hprof，OOM 后自动生成堆快照；再用 MAT（Eclipse Memory Analyzer）打开分析“Leak Suspects”和“Dominator Tree”，定位占用最大的对象及其引用链。
元空间溢出（Metaspace）
错误提示为 java.lang.OutOfMemoryError: Metaspace，常见于 JDK 8 及以后版本。
- 本质是类元数据（类名、字段、方法、常量池等）占用本地内存超标；
- 高频动态生成类的场景风险最高，比如大量使用 CGLIB 动态代理（Spring AOP 默认）、反复加载/卸载自定义类加载器、热部署框架（如 JRebel 未正确配置）；
- 字符串常量池已移至堆中，但频繁调用
String.intern()（尤其在 JDK 7 及以前）也曾是永久代溢出主因。
排查建议：用 jstat -gcmetacapacity <pid> 查看元空间使用趋势；通过 -XX:MaxMetaspaceSize=256m 设置上限防止无限增长；检查是否有重复定义或未卸载的类。
线程相关溢出（Unable to create new native thread）
报错为 java.lang.OutOfMemoryError: Unable to create new native thread，它不表示堆或元空间不足，而是操作系统层面的资源耗尽。
- 根本原因是 JVM 创建新线程时，系统无法分配新的内核线程（native thread），通常受限于：进程最大线程数限制（Linux 的
ulimit -u）、虚拟内存总量（每个线程默认栈大小约 1MB，1024 个线程就占 1GB 虚拟内存）； - 常见于线程池无界、异步任务未加限流、递归创建线程、或
-Xss（单线程栈大小）设置过大。
排查建议：用 ps -eLf | grep <pid> | wc -l 查看当前线程数；检查线程池配置是否合理（推荐使用有界队列+拒绝策略）；必要时调小 -Xss（如设为 256k），但需确保不引发 StackOverflowError。
直接内存溢出（Direct buffer memory）
错误提示为 java.lang.OutOfMemoryError: Direct buffer memory，与 NIO 的 ByteBuffer.allocateDirect() 直接相关。
- 直接内存不受 JVM 堆大小控制，由
-XX:MaxDirectMemorySize限制（默认等于-Xmx）； - Netty、Dubbo 等高性能网络框架大量使用堆外内存，若未及时调用
cleaner或free()释放，或频繁申请/释放小块直接内存，易造成碎片化和耗尽； - 部分国产 JDK 或旧版本存在 DirectBuffer 泄漏 bug，升级 JDK 有时可缓解。
排查建议：启用 -XX:+PrintGCDetails 观察 GC 日志中是否频繁出现 “Direct buffer memory” 相关统计；用 jmap -histo:live <pid> 查看 java.nio.DirectByteBuffer 实例数量；代码中确保 ByteBuffer 使用后显式清理或依赖 try-with-resources（JDK 9+ 支持）。
