内存泄漏是对象该回收未回收致堆空间渐少，内存溢出是分配时无足够内存而崩溃；需分四步排查：确认类型、三段快照比对、锁定四类高危模式、闭环验证修复。
内存泄漏和内存溢出是 Java 应用线上故障的高频原因，但二者常被混淆。简单说：内存泄漏是对象该回收却没被回收，长期累积导致可用堆空间越来越少；内存溢出（OutOfMemoryError）是某次分配时连“最后一块够用的内存”都找不到，直接崩溃。排查不能只看现象，得有一套分层定位、证据闭环的框架。
第一步：确认是溢出还是泄漏——看错误类型和增长节奏
不是所有 OutOfMemoryError 都等于内存泄漏。先快速归因：
-
直接报
java.lang.OutOfMemoryError: Java heap space，且发生在应用启动后几分钟内：大概率是堆配置过小或单次加载数据超限（如一次查 100 万条记录转 List），属于溢出，非泄漏； - 错误在运行数小时甚至几天后才出现，且 GC 日志显示老年代使用率持续缓慢上升，Full GC 后也降不下去：这是泄漏的典型信号；
-
报
Unable to create new native thread或Metaspace相关 OOM：说明问题不在堆，可能线程泄漏或类加载器未释放，需切换排查维度。
第二步：用基础工具做“三段快照”比对
不依赖复杂平台，仅靠 JDK 自带工具就能发现 80% 的泄漏线索。关键在“同一业务操作前后”的对比：
-
jstat -gc
1s ：持续观察 Young GC 频率、老年代占用趋势、MetaSpace 使用量，确认是否缓慢上涨； -
jmap -histo:live
（执行前先 kill -3触发一次 Full GC）：获取当前存活对象统计，重点关注数量异常多、单个实例大的类（如byte[]、自定义缓存 Map、未关闭的连接池对象）； -
jmap -dump:format=b,file=heap.hprof
：在疑似泄漏点前后各 dump 一次，用 JProfiler / Eclipse MAT 对比两个堆快照的“dominator tree”差异，看哪些对象及其引用链明显增长。
第三步：锁定泄漏源头——聚焦四类高危模式
90% 的泄漏来自固定场景，按优先级逐项排除：
-
静态集合类持有对象：如
public static Map<string object> cache = new HashMap();</string>，忘了设过期或清理机制； - ThreadLocal 未 remove()：尤其在线程池中，线程复用导致上一个请求存的值一直留在 ThreadLocalMap 里；
- 监听器/回调注册后未注销：GUI 或事件驱动框架中常见，对象被监听器强引用，无法 GC；
- 内部类持外部类引用导致生命周期延长：比如非静态内部类作为定时任务提交给 ScheduledExecutorService，只要定时器活着，外部类就无法回收。
第四步：验证修复——不止看不 OOM，要看回收是否干净
改完代码别急着上线。验证要闭环：
- 用相同压测路径重复执行 3–5 轮，每轮后手动触发
jmap -histo:live，确认可疑类实例数不再增长； - 检查 GC 日志中老年代峰值是否稳定，Full GC 后回收比例是否恢复正常（如能回收 60%+）；
- 如果用了弱引用/软引用做缓存，确保在内存紧张时确实被回收（可通过
-XX:+PrintGCDetails观察 Reference 处理日志）。
这套框架不追求一步到位，而强调“现象→指标→快照→模式→验证”的证据链。很多团队卡在第一步就靠猜，结果修了三天发现根本不是泄漏。稳住节奏，用数据说话，问题自然浮出水面。
