面试总结：内存泄漏与内存溢出的综合排查框架

面试总结：内存泄漏与内存溢出的综合排查框架

内存泄漏和内存溢出，这俩词在Java线上故障里出现频率极高，但很多人容易搞混。说白了：泄漏是对象该回收没被回收，日积月累把堆空间蚕食掉；溢出（OutOfMemoryError）是某一时刻分配内存时连最后那点空间都不够用了，直接崩给你看。排查不能光靠猜，得有一套分层定位、证据环环相扣的框架。

第一步：确认是溢出还是泄漏——看错误类型和增长节奏

不是所有OutOfMemoryError都跟泄漏有关。先快速归个类：

• 直接报java.lang.OutOfMemoryError: Java heap space，而且应用启动后几分钟就出现：大概率是堆设小了，或者单次加载数据量太大（比如一次查一百万条记录全塞进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 cache = new HashMap<>();，忘了设过期时间或者清理机制；
• ThreadLocal用完没remove()：尤其是在线程池里，线程被复用，结果上一个请求存的值一直赖在ThreadLocalMap里不走；
• 监听器/回调注册后没注销：GUI或者事件驱动框架里常见，对象被监听器强引用拽着，GC根本动不了它；
• 内部类持有外部类引用导致生命周期延长：比如非静态内部类作为定时任务丢给ScheduledExecutorService，只要定时器还活着，外部类就没法被回收。

第四步：验证修复——不止看不OOM，要看回收是否干净

改完代码别急着上线，验证得闭环：

• 用同样的压测路径重复3到5轮，每轮结束后手动触发jmap -histo:live，确认可疑类的实例数不再增长；
• 检查GC日志里老年代峰值是否稳定，Full GC之后的回收比例能否回到正常水平（比如能回收60%以上）；
• 如果用了弱引用或软引用做缓存，务必确认内存紧张时它们确实被回收了（可以通过-XX:+PrintGCDetails观察Reference处理日志）。

这套框架不追求一步到位，关键是把“现象→指标→快照→模式→验证”这条证据链走通。很多团队卡在第一步就开始瞎猜，结果折腾三天发现根本不是泄漏。稳住节奏，用数据说话，问题自然会浮出来。