Java内存泄漏常见原因：静态集合类及长生命周期对象

Java内存泄漏最常被忽视的是静态集合类、单例、非静态内部类及未关闭资源导致短命对象无法回收。需用WeakHashMap、WeakReference、try-with-resources等机制及时断开引用。

Java内存泄漏里，最常被忽视又最容易复现的，就是静态集合类和长生命周期对象“拖住”短命对象的问题。它不是JVM坏了，而是引用关系没及时断开，让GC以为这些对象还在用。

静态集合类：缓存变“黑洞”

static HashMap、ArrayList 等一旦声明，就活到应用结束。往里面 put 或 add 的对象，哪怕业务逻辑早已不用，只要没手动 remove 或 clear，就会一直驻留。

• 别直接用 static 集合做缓存；真要用，必须配清理机制——按时间（TTL）、按访问频次（LRU），或提供显式清理入口
• 临时数据优先用局部变量或 ThreadLocal，避免升级为全局引用
• 如果 key 是临时对象，考虑用 WeakHashMap：key 只被它引用时，GC 可正常回收

单例与全局管理器：隐性“强绑定”

单例、Application、全局事件总线等，生命周期和 App 一样长。一旦它们持有了 Activity、Fragment、监听器这类短命对象的强引用，后者就跟着“卡住”不释放。

• 注册监听器后，务必在对应生命周期终点解注册（如 onDestroy、onDestroyView）
• 对可能短命的对象，用 WeakReference 包一层，比如 WeakReference 或 WeakReference
• 避免在单例中直接持有 UI 组件或回调实例，改用接口回调 + 弱引用组合

非静态内部类：悄悄拽住外部类

Handler、AsyncTask 匿名子类、线程任务等，如果写成非静态内部类，会隐式持有外部类（比如 Activity）的强引用。一旦这个内部类被投递到主线程消息队列或线程池里长期待命，Activity 就无法回收。

立即学习“Java免费学习笔记（深入）”；

• 改为 static 内部类，通过 WeakReference 持有外部实例
• Handler 创建时传入 Looper.getMainLooper()，并确保在 Activity 销毁时 removeCallbacksAndMessages(null)
• 异步任务完成后，检查是否还持有上下文，必要时清空引用

资源未关闭：不只是堆内存问题

Connection、InputStream、Socket、Cursor 这些对象背后连着操作系统资源（文件句柄、socket 描述符）。不 close，不仅堆内对象不释放，更可能先耗尽系统级资源，引发 IOException 或崩溃。

• 所有可关闭资源，必须放在 try-with-resources 中，或至少保证 finally 块里调用 close()
• 自定义资源类实现 AutoCloseable，close() 方法需幂等、可重入
• 连接池（如 HikariCP）能缓解压力，但不能替代代码层的 close 责任

不复杂但容易忽略。关键不在“设 null”，而在让引用待在该待的地方、及时松手。