JVM内存异常需结合区域特性判断：堆OOM因对象堆积，Metaspace因类加载过多，栈溢出因递归过深，Direct Memory因NIO未释放。关键看谁在用、怎么满、线索在哪。
JVM内存结构各区域异常类型不能靠背名字判断，得看“谁在用、怎么满、报错时上下文线索在哪”。不同区域的OOM或Error背后机制完全不同，混淆了就容易调错参数、漏掉真实问题。
堆（Heap）：对象堆积导致的OOM最常见
几乎所有new出来的对象都在这里分配。异常表现和排查重点很明确：
- OutOfMemoryError: Java heap space：堆空间耗尽，典型如内存泄漏（缓存未清理、监听器未注销）、大对象反复创建、堆设置过小。
- OutOfMemoryError: GC Overhead limit exceeded：GC花98%以上时间却只回收不到2%内存，本质是堆里有效对象太多、垃圾难清，往往也是内存泄漏的间接信号。
- 关键线索：堆内存监控（如Metaspace不涨、老年代持续攀升）、GC日志显示Full GC频繁但回收量少。
方法区（Java 8+ 是 Metaspace）：类元数据撑爆本地内存
这里不存对象实例，而是存Class结构、常量池、静态变量、JIT编译代码。出问题多和“加载太多类”有关：
- OutOfMemoryError: Metaspace：动态生成类过多（如大量使用CGLIB、ASM、Spring AOP代理）、热部署频繁、反射调用触发类重复加载。
- 注意：它用的是本地内存（Native Memory），不受-Xmx限制，需单独调参：
-XX:MaxMetaspaceSize。 - 关键线索：jstat -gc输出中MCM/MCU（Metaspace容量/已用）持续增长；jmap -cl显示类加载器数量异常高。
虚拟机栈 & 本地方法栈：深度或容量问题
两者都是线程私有，异常类型相同但触发场景有区别：
- StackOverflowError：栈深度超限，几乎全是无限递归（比如toString()里又调自己、equals里没判null）或极深的嵌套调用。
- OutOfMemoryError: unable to create new native thread（不是栈OOM，但常被误认）：其实是操作系统级线程创建失败，根源往往是线程数过多（如线程池未限制、短生命周期线程滥用），把系统资源耗尽了。
- 关键线索：异常堆栈末尾反复出现同一方法名（递归特征）；线程dump里线程数远超预期（如几百上千个RUNNABLE线程）。
直接内存（Direct Memory）：NIO场景下的隐形炸弹
它不属于运行时数据区，但由JVM管理，用ByteBuffer.allocateDirect()分配，绕过堆直连OS内存：
-
OutOfMemoryError: Direct buffer memory：NIO读写文件/网络时未及时释放DirectBuffer，或
-XX:MaxDirectMemorySize设得太小（默认等于-Xmx）。 - 特别隐蔽：堆内存监控一切正常，但进程RSS（常驻集）持续上涨，最终被OS kill。
- 关键线索：用
jstat -gc看DCC/DUC（Direct Buffer容量/已用）；用pmap -x [pid]查进程内存映射中大块anon-rw段。
真正区分异常，不是记住报错字符串，而是结合线程模型（私有/共享）、内存来源（堆内/堆外/本地）、以及你代码里正在做什么操作——new对象？加载类？递归计算？读写文件？每一步都对应着某块内存区域的真实压力点。
