单例模式导致内存泄漏的根源在于其长期持有短生命周期对象的强引用。应改用application context、使用weakreference包装临时对象、提供clear()方法显式清理、或用静态工具类替代有状态单例。
单例模式本身不是问题，问题出在它持有短生命周期对象的强引用上。由于单例生命周期与应用一致，一旦它长期持有一个本该被回收的对象（比如 Activity、Context、Fragment 或临时业务对象），这个对象就永远无法释放。
避免在单例中直接持有 Context 或 UI 组件
常见错误是把 Activity 的 Context 传给单例并赋值给成员变量。Activity 销毁后，单例仍强引用着它，导致整个 Activity 及其关联视图、资源无法回收。
- 改用 Application Context：它生命周期与应用一致，不会因 Activity 销毁引发泄漏
- 不要在单例构造或初始化时接收 Activity/Fragment 实例作为参数
- 若必须传入上下文，统一通过
getApplicationContext()获取，并确保不存储原始 Activity 引用
对必须缓存的短生命周期对象使用弱引用
当单例确实需要临时访问某个易销毁对象（如监听回调中的用户数据、临时配置），不能用强引用保存。
- 用
WeakReference<t></t>包装，例如：private WeakReference<user> currentUserRef;</user> - 使用前检查
currentUserRef.get() != null，避免空指针 - 不依赖弱引用做关键状态判断，仅用于“可有可无”的辅助场景
提供显式清理入口，主动断开引用
有些场景下弱引用不够用（比如需保证对象存活到某操作完成），那就得靠人工干预。
- 在单例中添加
clear()或releaseResources()方法 - 在 Activity onDestroy()、Fragment onDetach() 等合适时机调用该方法
- 方法内部将所有可能造成泄漏的成员变量置为
null，例如：this.context = null;、this.listener = null;
优先用静态工具类替代带状态的单例
如果单例只是封装一组通用方法（如网络请求、日志打印、加密解密），其实不需要维护实例状态。
- 改为纯静态工具类，所有方法都是
static，不持任何实例字段 - 彻底规避“持有引用”问题，也更轻量、线程安全、易于测试
- 例如：
NetworkUtils.post(...)而非NetworkManager.getInstance().post(...)
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
