单例模式导致内存泄漏的根源在于强引用短生命周期对象。应使用Application Context替代Activity Context，用WeakReference包装临时对象，提供clear()等显式清理方法，并以WeakHashMap替代静态集合。

单例模式本身不是问题，问题出在它“持有了不该持有的引用”。因为单例生命周期与应用一致，只要它强引用着某个短命对象（比如 Activity、Context、Listener 等），那个对象就永远无法被 GC 回收，内存就一直占着。

用 Application Context 替代 Activity Context

Android 开发中最典型场景：单例中保存了 Activity 的 Context。Activity 销毁后，单例仍拿着它的引用，导致整个 Activity 及其关联的 View、Bitmap 等都无法释放。

解决办法是只持有 Application 的 Context——它的生命周期和应用一致，不会早于单例销毁。

• 初始化单例时传入 getApplicationContext()，而非 this 或 getActivity()
• 单例内部用 Context.getApplicationContext() 统一获取并缓存
• 避免在单例中直接接收或存储 Activity、Fragment、View 等 UI 组件实例

避免强引用短生命周期对象

如果业务确实需要在单例中暂存某些临时对象（如用户配置、临时回调），不能简单用普通字段持有。

java-api-doc-generator

分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。

下载

• 改用 WeakReference 包装，例如：private WeakReference userRef;
• 使用前先 get() 并判空，因为弱引用对象可能已被回收
• 不依赖弱引用做关键逻辑，仅用于缓存类轻量数据

提供显式清理机制

当单例需要阶段性管理外部对象（比如监听器、资源句柄），必须支持主动断开引用。

• 在单例中定义 clear()、release() 或 onDestroy() 方法
• 在合适的时机（如 Activity onDestroy()、Fragment onDetach()）调用该方法
• 方法体内将所有外部引用设为 null，或从集合中移除对应项

静态引用需谨慎搭配作用域

单例常以 static 字段实现，而 static 本身就会延长对象生命周期。若再配合静态集合（如 static Map）、静态监听器列表，风险叠加。

• 静态集合中存放的对象，除非手动 remove，否则永不释放
• 考虑用 WeakHashMap 替代 HashMap，键为弱引用，GC 可自动清理失效条目
• 对注册型单例（如事件总线），务必配套反注册机制，并确保调用时机可靠

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南