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

在Java的内存泄漏问题里，有一种特别容易让人忽略，但出现频率极高的场景，就是静态集合类和那些活得太久的对象，把本该回收的短命对象牢牢“拽”住了。这可不像JVM自身出了什么大毛病，根子就在于引用关系没及时断开——GC扫到它们的时候，还以为这些对象仍然在“服役”，于是放过了回收的窗口。

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

static HashMap 或 ArrayList 这类集合，一旦声明，它们的生命周期就几乎与整个应用同进退。往里面 put 或 add 进去的对象，哪怕业务逻辑早就用不上了，只要没手动 remove 或 clear，就会一直赖在内存里不走。问题往往出在：开发者以为它只是临时缓存，结果它变成了内存黑洞。

• 日常开发中，别图省事直接用 static 集合做缓存。真要这么用，配套的清理机制必须跟上——比如按时间过期（TTL）、按访问频率淘汰（LRU），或者提供一个显式清理的入口供主动调用。
• 临时数据优先考虑局部变量或 ThreadLocal，避免一不小心升级为全局引用。
• 如果 key 是临时对象，WeakHashMap 是个好帮手：key 只被它引用时，GC 可以正常回收，算是一种隐形的自清理机制。

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

单例、Application 对象、全局事件总线这类组件，生命周期和整个应用一样长，属于内存里的“常驻户”。一旦它们持有了 Activity、Fragment、或者某个监听器的强引用，后者哪怕业务上早该销毁了，也会被强行“卡”住，没法释放。这往往是最容易被忽略的泄漏路径。

• 注册监听器之后，必须找到对应的生命周期终点（比如 onDestroy、onDestroyView）进行反注册。
• 对于可能短命的对象，可以用 WeakReference 包一层，比如 WeakReference 或 WeakReference，让GC能绕过这层引用正常回收。
• 单例里最好别直接持有UI组件或回调实例，改用接口回调 + 弱引用的组合，更稳妥。

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

Handler、AsyncTask 匿名子类、或者线程任务，如果被写成非静态内部类，就会隐式持有外部类（比如 Activity）的强引用。这个内部类一旦被投递到主线程的消息队列或线程池里长期待命，外部类就永远别想逃出GC的回收列表。从实战经验来看，这是内存泄漏排查中的常客。

• 改成 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”就能解决问题，而是要让引用待在它该待的地方，并在恰当的时机果断松手。