Java内存泄漏是指对象逻辑上已废弃但因被GC Roots强引用而无法回收。典型场景包括：1.静态集合长期持有对象；2.ThreadLocal未remove导致value残留；3.非静态内部类隐式持有外部类引发Activity等对象无法释放。
Java 内存泄漏不是“GC 失效”或“对象没被释放”，而是对象逻辑上已无用，但因被 GC Roots 强引用着，导致无法回收。回答时抓住三点：定义准确、原因清晰、例子典型，避免说“Java 有 GC 就不会泄漏”这种错误前提。
一、先说清楚本质定义
Java 内存泄漏的核心判断标准有两个：
- 对象在程序中已经不会再被使用（业务逻辑上废弃）
- 但该对象仍能从 GC Roots（如栈帧变量、静态字段、JNI 引用等）被可达访问
只要同时满足这两点，JVM 就认为它“还在用”，不会回收——哪怕你写了 obj = null，只要集合、监听器、缓存等持有它的强引用，泄漏就成立。
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
二、重点讲 3 个高频场景（面试最爱问）
1. 静态集合长期持有对象
比如 public static List<Object> cache = new ArrayList<>(); 不断 add 对象，却不清理。即使业务侧不再需要这些对象，static 引用让它们永远可达。
2. ThreadLocal 使用不当
ThreadLocal 的 key 是弱引用，value 是强引用。若线程复用（如线程池中），而没调用 remove()，value 就会一直留在 ThreadLocalMap 中，造成泄漏。
3. 内部类/监听器未解绑
非静态内部类隐式持有外部类引用。例如 Activity 中创建 Handler 或 AsyncTask，Activity 销毁后，若 Handler 还在消息队列里排队，或 AsyncTask 仍在执行，就会让整个 Activity 实例无法回收。
三、如何排查和解决（体现工程能力）
不只讲理论，要带方法：
立即学习“Java免费学习笔记（深入）”；
- 监控：用 JVisualVM / JConsole 观察堆内存趋势 + Full GC 频次；加
-XX:+HeapDumpOnOutOfMemoryError自动导出 dump 文件 - 分析：用 MAT（Memory Analyzer Tool）打开 hprof 文件，看 Dominator Tree 找大对象，再查 Path to GC Roots 确认谁在强引用它
- 预防：静态集合加容量限制和过期策略；ThreadLocal 用完必
remove()；注册监听器的地方，务必在生命周期结束时反注册
四、一句话收尾（加分项）
内存泄漏不是 JVM 的 bug，而是代码对对象生命周期的误判——我们写的是逻辑，JVM 看的是引用图。真正靠谱的做法，是让引用关系与业务生命周期严格对齐。
