内存泄漏是“该回收的没回收”，内存溢出是“堆空间不够用了”；前者因残留引用致对象长期存活、GC无法回收，渐进式恶化；后者是内存分配失败直接抛OutOfMemoryError，可能由泄漏引发，也可能源于瞬时大内存需求或配置不当。
内存泄漏和内存溢出是 Java 面试中高频出现的 JVM 相关考点，本质区别在于：内存泄漏是“该回收的没回收”，内存溢出是“堆空间不够用了”。理解二者成因、现象、排查手段，才能在面试中答得准、答得稳。
内存泄漏：对象长期存活，GC 无法回收
内存泄漏不是一次性事件，而是持续积累的过程。典型表现是老年代使用率缓慢上升，Full GC 后回收效果差，最终可能触发 OOM。
- 常见泄漏场景：静态集合类（如 static Map）不断 put 对象；未关闭的资源（IO 流、数据库连接、监听器）；ThreadLocal 使用不当（尤其在线程池中未 remove）；内部类持有外部类引用导致 Activity 或 Handler 泄漏（Android 场景）。
- 判断依据：用 jstat 观察老年代使用率是否随时间单向增长；用 jmap + MAT 分析 heap dump，查看 dominated heap 中是否存在异常大的对象图，重点关注 GC Roots 的强引用链。
- 修复关键：及时释放无用引用（置 null、remove、close）；优先使用弱引用/软引用管理缓存；避免在静态上下文中长期持有业务对象；线程池中使用 ThreadLocal 时务必在 finally 块调用 remove()。
内存溢出：分配失败，直接抛 OutOfMemoryError
溢出是结果，泄漏只是诱因之一。JVM 各内存区域都可能溢出，需结合错误信息定位具体区域。
- 堆溢出（java.lang.OutOfMemoryError: Java heap space）：最常见。可能是内存泄漏，也可能是堆设置过小或短时大对象分配（如一次加载 500MB 文件）。可通过 -Xmx 调整，但更应检查对象生命周期和大小。
- 元空间溢出（java.lang.OutOfMemoryError: Metaspace）：类加载过多（如动态生成大量代理类、频繁 redeploy 应用）。可通过 -XX:MaxMetaspaceSize 限制，配合 -XX:+PrintGCDetails 查看类卸载情况。
- 栈溢出（java.lang.StackOverflowError）：方法调用深度超限（如递归无出口），或单帧过大（局部变量表爆炸）。与 -Xss 设置有关，但多数情况是代码逻辑问题。
- 直接内存溢出（java.lang.OutOfMemoryError: Direct buffer memory）：NIO 使用 ByteBuffer.allocateDirect() 未显式 clean，或 Netty 等框架未释放 pooled direct buffer。可通过 -XX:MaxDirectMemorySize 控制。
排查工具链：从现象到根因
面试官常问“怎么发现并定位问题”，重点考察实操思路而非命令背诵。
- 监控阶段：用 jstat -gc pid 每秒观察 YGC、FGC 频率及各区变化；用 VisualVM 或 JConsole 连接远程 JVM，直观查看内存曲线和 GC 日志。
- 快照分析：发生 OOM 时加参数 -XX:+HeapDumpOnOutOfMemoryError 自动导出 dump；用 MAT 打开后看 Leak Suspects 报告，或用 Dominator Tree 查找大对象及其引用路径。
- 日志辅助：开启 -XX:+PrintGCDetails -Xloggc:gc.log，结合 GC 时间、晋升失败（Promotion Failed）、并发模式失败（Concurrent Mode Failure）等线索判断问题类型。
预防与设计意识：不止于“修 Bug”
高级岗位会关注候选人的工程化思维。内存问题本质是资源管理意识的体现。
- 编码习惯：集合使用前预估容量（避免频繁扩容）；大对象优先考虑流式处理或分页；缓存加过期策略和大小限制（如 Caffeine）。
- 框架选型：注意 ORM 框架的 fetch 策略（避免 N+1 和全量加载）；消息队列消费者要控制批量拉取大小；RPC 客户端留意连接池和序列化缓冲区配置。
- 上线守则：JVM 参数不盲目调大堆内存，先做压测验证 GC 行为；生产环境必开 GC 日志；关键服务部署前做内存 baseline 测量。
不复杂但容易忽略——真正区分候选人水平的，不是能否背出 OOM 类型，而是能否结合场景讲清“为什么这里会泄漏”“为什么调堆解决不了根本问题”“这个 dump 里哪条引用链说明了问题”。
