单例模式导致内存泄漏的根源在于强引用短生命周期对象。应使用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 代码生成文档”时触发。
立即学习“Java免费学习笔记（深入）”；
- 改用 WeakReference 包装，例如：
private WeakReference<user> userRef;</user> - 使用前先 get() 并判空，因为弱引用对象可能已被回收
- 不依赖弱引用做关键逻辑，仅用于缓存类轻量数据
提供显式清理机制
当单例需要阶段性管理外部对象（比如监听器、资源句柄），必须支持主动断开引用。
- 在单例中定义 clear()、release() 或 onDestroy() 方法
- 在合适的时机（如 Activity onDestroy()、Fragment onDetach()）调用该方法
- 方法体内将所有外部引用设为 null，或从集合中移除对应项
静态引用需谨慎搭配作用域
单例常以 static 字段实现，而 static 本身就会延长对象生命周期。若再配合静态集合（如 static Map）、静态监听器列表，风险叠加。
- 静态集合中存放的对象，除非手动 remove，否则永不释放
- 考虑用 WeakHashMap 替代 HashMap，键为弱引用，GC 可自动清理失效条目
- 对注册型单例（如事件总线），务必配套反注册机制，并确保调用时机可靠
