java内存泄漏和oom本质是堆内存被无用对象长期占用且无法gc回收，排查需按“抓快照→看分布→找引用链→定位代码”四步进行，并关注metaspace、直接内存、线程数等非堆oom场景。
Java内存泄漏和OOM（OutOfMemoryError）本质是堆内存长期被无用对象占用，无法被GC回收，最终导致内存耗尽。排查核心思路是：抓快照 → 看对象分布 → 找强引用链 → 定位代码源头。
一、快速确认是否真有内存泄漏
别一上来就看堆转储。先观察运行时表现：
- JVM启动加 -XX:+PrintGCDetails -Xloggc:gc.log，看Full GC是否频繁且每次回收后老年代内存不下降
- 用 jstat -gc
持续监控，重点关注 OGCMN/OGCMX（老年代初始/最大值）、OGC（当前老年代使用量）、OC（老年代容量） —— 若OGC持续逼近OC且不回落，大概率泄漏 - 用 jmap -histo:live
对比两次结果，看某些对象实例数是否只增不减（如HashMap、ArrayList、自定义DTO、监听器等）
二、生成并分析堆转储（Heap Dump）
确认异常后，立即导出堆快照（避免二次GC干扰）：
-
jmap -dump:format=b,file=heap.hprof
（生产环境慎用，会暂停应用；可加 -F 强制，但可能不完整） - 更推荐在JVM启动时加参数自动触发：-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/path/to/dumps/
- 用 Eclipse MAT（Memory Analyzer Tool） 打开hprof文件，点 “Leak Suspects Report” —— 它会自动标出最可能泄漏的几个对象组及支配树（Retained Heap占比高、GC Roots强引用链长的对象优先看）
三、常见泄漏场景与修复方式
不必盲目猜，90%问题集中在以下几类：
立即学习“Java免费学习笔记（深入）”；
-
静态集合类持有对象：如 public static Map
cache = new HashMap(); 忘记清理或没设过期策略 → 改用 WeakHashMap / Caffeine / 加定时清理线程 - 内部类/匿名类隐式持外部类引用：非静态内部类会持外部this；若该内部类被线程池、监听器等长期引用，外部类也泄漏 → 改为静态内部类 + 显式传参，或用WeakReference包装外部引用
- 未关闭资源导致关联对象驻留：InputStream、Connection、ThreadLocal、ScheduledExecutorService中的Runnable → 确保finally块中close() / remove() / shutdown()
- 第三方库不当使用：如Netty的ByteBuf未release()、OkHttp的Call未cancel()、Spring中@EventListener未加@Async却处理耗时逻辑 → 查文档，严格遵循生命周期管理
四、OOM不是只有堆内存问题
别只盯着-heap。其他常见OOM类型和对策：
- java.lang.OutOfMemoryError: Metaspace → 类加载过多（热部署、动态字节码生成），加 -XX:MaxMetaspaceSize=256m 并检查是否重复加载类
- java.lang.OutOfMemoryError: Direct buffer memory → NIO直接内存超限，加 -XX:MaxDirectMemorySize=512m，并确保ByteBuffer.allocateDirect()后调用cleaner或手动clean()
- java.lang.OutOfMemoryError: unable to create new native thread → 线程数超系统限制，检查是否无限创建Thread、线程池配置不合理、或ulimit -u太小
基本上就这些。关键是养成习惯：上线前加基础JVM监控参数，压测时关注GC日志和内存趋势，出问题时不靠“重启解决”，而是保留现场再分析。工具只是辅助，真正要盯住的是对象之间的引用关系——谁在死死拽着不该活的对象不放。
