OOM本质是JVM申请内存时可用空间不足且GC无法释放足够空间而触发的保护性崩溃；关键在于定位“哪块内存满”及“为何满”，常见类型包括堆、元空间、栈、直接内存等溢出。
JVM 内存溢出（OutOfMemoryError，简称 OOM）不是单一问题，而是多种内存区域失衡的集中表现。它本质是 JVM 在申请内存时，发现当前可用空间不足，且无法通过垃圾回收释放足够空间，最终触发保护性崩溃。真正关键的，不在于“报错内容”，而在于“哪块内存满了”以及“为什么满”。
堆内存溢出（Java heap space）
这是最常见、最典型的 OOM 场景，错误形如 java.lang.OutOfMemoryError: Java heap space。
- 根本原因只有两类：一是内存泄漏——对象已无业务用途，却因静态引用、缓存未清理、监听器未注销、内部类隐式持有所致，始终被 GC Root 可达，无法回收；二是内存确实不够用——比如一次性加载 50 万条数据库记录、解析超大 JSON、生成巨量临时对象，超出堆配置上限。
- 排查建议：启动时加参数 -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=./dump.hprof，OOM 发生后自动生成堆快照；再用 MAT 或 JProfiler 打开，按“Dominator Tree”查看谁占了最多内存，结合“Path to GC Roots”追溯强引用链。
- 临时缓解可调大堆：-Xms4g -Xmx4g（建议初值与最大值一致，避免扩容抖动），但若存在泄漏，这只是延缓崩溃，不是解决。
元空间溢出（Metaspace）
错误提示为 java.lang.OutOfMemoryError: Metaspace，多见于频繁动态生成类的场景（如大量使用 CGLIB、Spring AOP、热部署、OSGi、字节码增强框架）。
- 元空间使用本地内存，不受堆大小限制，但受操作系统资源约束。溢出往往意味着类加载器没被卸载，旧类一直堆积（典型如 Tomcat 热部署后旧 ClassLoader 残留）。
- 可加参数 -XX:MaxMetaspaceSize=256m 显式设限，便于早暴露问题；配合 -XX:+PrintGCDetails 观察元空间 GC 日志，确认是否发生类卸载。
- 代码侧需检查：是否过度使用
Class.forName或反射；是否在循环中反复定义 Lambda 或匿名类；Web 应用是否缺少 contextDestroyed 清理逻辑。
栈相关异常：StackOverflowError 与栈内存 OOM
注意区分：StackOverflowError 是单线程调用栈深度超限（如无限递归），错误信息明确不含 “OutOfMemoryError”；而 java.lang.OutOfMemoryError: unable to create new native thread 才是栈内存层面的 OOM，本质是线程数过多耗尽了操作系统级线程栈资源。
- 前者靠修复递归出口、改用迭代、减小局部变量体积来解决；
- 后者则要控制线程创建——检查是否无限制 new Thread()、线程池配置过大、或未复用连接池/HTTP 客户端实例；同时可调小单线程栈大小：-Xss256k（默认通常 1M），但需避免过小引发新 StackOverflow。
直接内存与本地内存溢出
使用 NIO 的 ByteBuffer.allocateDirect()、Netty 的 PooledByteBufAllocator 或 JNI 调用时，可能触发 java.lang.OutOfMemoryError: Direct buffer memory 或更底层的本地内存耗尽。
- 直接内存不受 -Xmx 控制，由 -XX:MaxDirectMemorySize 限定（默认等于 -Xmx）；若未显式设置，容易在堆不大但 direct buffer 疯涨时突然失败。
- 常见诱因：Netty 中 Channel 不关闭导致 pooled buffer 无法回收；大量短生命周期的 direct buffer 分配未及时清理；或 ByteBuffer 使用后未调用
cleaner.clean()（虽通常由 GC 触发，但有延迟）。 - 监控建议：通过 jstat -gc <pid> 查看 MCMN/MCMX（元空间容量）和 CCSC/CCSM（压缩类空间），配合 jcmd <pid> VM.native_memory summary 观察直接内存用量。
