jvm内存溢出需按区域精准定位：堆溢出因对象堆积，应优化引用与缓存；元空间溢出由类加载失控，需控制动态类生成；栈溢出系递归或嵌套过深，宜改迭代并断循环引用；直接内存溢出因nio资源未释放，须确保资源关闭与池化管理。
JVM 内存溢出不是单一问题，而是多种内存区域超限的统称。定位关键不在“加内存”，而在识别具体溢出区域、理解代码行为与JVM内存模型的耦合关系，并针对性重构。
堆内存溢出：对象堆积与引用滞留
这是最常见场景，错误日志为 java.lang.OutOfMemoryError: Java heap space。本质是新生代或老年代无法容纳新对象，或大量对象因被意外持有而无法回收。
- 典型代码陷阱：静态集合持续添加不清理（如
private static List<string> cache = new ArrayList();</string>）、监听器未反注册、ThreadLocal 变量未 remove、缓存未设上限或淘汰策略 - 重构重点：用弱引用（
WeakReference）或软引用管理缓存；改用 Guava Cache 或 Caffeine，启用大小限制与过期策略；将静态集合改为实例变量，生命周期与业务对象对齐；所有注册类操作配对实现注销逻辑 - 验证方式：启动时加
-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/tmp/heap.hprof，OOM 后用 MAT 分析 dominator tree，看哪些对象占大头、谁在强引用它们
元空间溢出：类加载失控
错误日志为 java.lang.OutOfMemoryError: Metaspace，多见于频繁动态生成类的场景（如 Spring AOP、MyBatis 动态代理、Groovy 脚本、OSGi 插件系统）。
- 典型诱因：热部署未卸载旧类加载器、反射大量调用
Class.forName、CGLib 为每个代理类生成新类、未关闭自定义 ClassLoader - 重构重点：避免运行时无节制生成类；使用
ClassLoader时确保其可被 GC（不持静态引用、及时 close）；升级框架版本修复已知类加载器泄漏（如老版 Spring Boot DevTools）；限制元空间大小（-XX:MaxMetaspaceSize=256m）迫使问题提前暴露 - 验证方式：用
jstat -gc <pid></pid>观察MU（Metaspace Used）持续增长；用jcmd <pid> VM.native_memory summary</pid>查看类元数据占用
栈内存溢出：调用链失控
错误为 java.lang.StackOverflowError，非内存不足，而是单线程栈帧深度超限，通常由递归失控或深层嵌套调用引起。
- 典型代码模式：无终止条件的递归（如树遍历未判空）、JSON 序列化循环引用、AOP 增强导致方法调用链意外延长
- 重构重点：递归改迭代（显式维护栈结构）；对深层嵌套逻辑拆分职责，引入中间状态；序列化时用
@JsonIgnore或JsonIdentityInfo断循环引用；检查代理配置，避免增强逻辑形成闭环 - 验证方式：增加
-Xss512k仅作临时排查；核心是代码审查调用栈深度，用jstack <pid></pid>抓取线程快照，观察重复出现的方法链
直接内存溢出：NIO 资源未释放
错误日志为 java.lang.OutOfMemoryError: Direct buffer memory，源于 ByteBuffer.allocateDirect() 分配的堆外内存超出限制。
- 典型原因：Netty 等框架中 Channel 不关闭导致 PooledByteBufAllocator 无法回收；手动分配 direct buffer 后未调用
cleaner或free()；高并发下 buffer 分配速率远超释放速率 - 重构重点：确保 Channel、Socket 等资源在 finally 块或 try-with-resources 中关闭；优先使用框架内置池化机制（如 Netty 的
PooledByteBufAllocator）；监控java.nio.Bits.reservedMemoryMBean 指标；设置-XX:MaxDirectMemorySize=512m显式约束 - 验证方式：用
jstat -gc <pid></pid>观察CCSU（Compressed Class Space Used）无关，重点看jcmd <pid> VM.native_memory detail</pid>中direct部分
