静态集合类、未关闭资源、ThreadLocal、Android Context 引用是四大内存泄漏主因；应分别采用 WeakHashMap、try-with-resources、threadLocal.remove()、ApplicationContext 等方案防范。
静态集合类持有对象引用导致泄漏
静态 HashMap、ArrayList 等若长期持有业务对象（如 User、Activity），而未及时清理，会阻止 GC 回收——尤其在 Web 应用或 Android 中很常见。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 改用
WeakHashMap存储缓存类数据，键为弱引用，GC 时自动剔除失效条目 - 若必须用静态集合，配合定时清理（如
ScheduledExecutorService）或显式调用clear() - 避免将非静态内部类实例（含隐式持有所属外部类引用）放入静态集合
未关闭的资源（IO / 数据库连接）引发泄漏
忘记关闭 InputStream、Connection、Statement 等资源，不仅耗尽连接池，还会因关联的本地句柄（如文件描述符）无法释放，间接拖慢整个 JVM。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 始终使用 try-with-resources：
try (FileInputStream fis = new FileInputStream("a.txt")) { // do something } // 自动 close() - 数据库操作中，确保
Connection、PreparedStatement、ResultSet都在 finally 或 try-with-resources 中释放 - 自定义资源类需实现
AutoCloseable，并在线程安全场景下注意 close() 的幂等性
线程与 ThreadLocal 使用不当
ThreadLocal 的 value 实际存储在当前线程的 ThreadLocalMap 中，若线程复用（如线程池中的 worker 线程）且未手动 remove()，value 会持续累积，尤其当 value 是大对象或含 ClassLoader 时，极易引发 OOM 和 ClassLoader 泄漏。
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 每次使用完
ThreadLocal.set()后，在同一线程上下文中显式调用threadLocal.remove() - 避免在
ThreadLocal中存放大对象（如byte[]、Map），优先考虑方法局部变量 - Web 应用中，可在 Filter 或拦截器末尾统一
remove()，确保请求生命周期结束即清理
Android 中 Context 引用泄漏（Java 层）
传入 Activity 或 Application Context 给单例、静态工具类、异步任务（如 AsyncTask、Handler），若这些组件生命周期长于 Activity，就会导致 Activity 无法回收。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 能用
getApplicationContext()就不用this或Activity.this，尤其在初始化单例、注册广播、启动服务时 - 异步回调中避免直接持有 Activity 成员变量；改用
WeakReference<activity></activity>判断是否 still alive - 使用
Handler时，务必声明为static，并通过弱引用来访问外部类状态
真正难排查的内存泄漏，往往藏在「本该短命却意外变长」的引用链里——比如一个被线程池反复执行的 Runnable 持有 Activity，或者某个第三方 SDK 的监听器没被 unregister。用 jmap + mat 抓 heap dump 时，重点看 dominated refs 和 path to GC roots，别只盯着“最大的对象”。
