静态集合类、未关闭资源、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免费学习笔记（深入）”；
- 每次使用完
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，别只盯着“最大的对象”。
