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

作者：袖梨 2026-07-13

内存泄漏是对象该回收未回收致堆空间渐少，内存溢出是分配时无足够内存而崩溃；需分四步排查：确认类型、三段快照比对、锁定四类高危模式、闭环验证修复。

内存泄漏和内存溢出是 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 <pid> 1s：持续观察 Young GC 频率、老年代占用趋势、MetaSpace 使用量，确认是否缓慢上涨；
jmap -histo:live <pid>（执行前先 kill -3 触发一次 Full GC）：获取当前存活对象统计，重点关注数量异常多、单个实例大的类（如 byte[]、自定义缓存 Map、未关闭的连接池对象）；
jmap -dump:format=b,file=heap.hprof <pid>：在疑似泄漏点前后各 dump 一次，用 JProfiler / Eclipse MAT 对比两个堆快照的“dominator tree”差异，看哪些对象及其引用链明显增长。

第三步：锁定泄漏源头——聚焦四类高危模式

90% 的泄漏来自固定场景，按优先级逐项排除：

静态集合类持有对象：如 public static Map<String, Object> cache = new HashMap<>();，忘了设过期或清理机制；
ThreadLocal 未 remove()：尤其在线程池中，线程复用导致上一个请求存的值一直留在 ThreadLocalMap 里；
监听器/回调注册后未注销：GUI 或事件驱动框架中常见，对象被监听器强引用，无法 GC；
内部类持外部类引用导致生命周期延长：比如非静态内部类作为定时任务提交给 ScheduledExecutorService，只要定时器活着，外部类就无法回收。