单例本身不会直接导致内存溢出，但易引发内存泄漏；应避免持有activity等短生命周期对象的强引用，优先使用application context，必要时用weakreference，并提供clear()等显式清理方法。
单例本身不会直接导致内存溢出（OOM），但它极易引发内存泄漏，而长期积累的泄漏最终会耗尽堆空间，触发 OutOfMemoryError。关键在于：单例生命周期与应用一致，若它持有了不该长期持有的对象（尤其是 Activity、Context、View、监听器等短生命周期对象），这些对象就无法被回收。
单例中避免持有短生命周期对象的强引用
Android 开发中最典型的问题是把 Activity 或 Context 直接传给单例并保存为成员变量。Activity 销毁后，只要单例还强引用着它，整个 Activity 及其关联的 View、Bitmap、资源等都无法释放。
- 改用 Application Context：如需 Context，优先使用
getApplicationContext()，它的生命周期与进程一致，不随 Activity 销毁而失效 - 禁用 Activity/Fragment Context：不要在单例构造或初始化时传入 Activity.this 或 this（在 Fragment 中）
- 必要时用弱引用：若业务确实需要临时绑定 UI 组件，可封装为
WeakReference<activity></activity>，并在使用前判空
提供显式清理机制
单例不应假设外部对象“永远有效”。当所依赖的组件（如回调、监听器、缓存数据）不再需要时，单例应支持主动断开引用。
- 定义
clear()、release()或onDestroy()类方法，在 Activity onDestroy() 中调用 - 清空所有非静态、非必要字段：例如
this.listener = null;、this.cacheMap.clear(); - 避免在单例内部注册未解注册的广播、RxJava 订阅、LiveData 观察者等
精简单例职责，拒绝“上帝类”设计
一个单例承载太多功能（网络、缓存、DB、UI 管理）会天然增加引用风险。职责越重，越容易无意中持住不该持的对象。
- 按领域拆分：用多个轻量级单例替代大而全的 Manager，例如
NetworkClient、ImageLoader、PreferenceHelper - 只保留真正需要全局共享的状态：比如 token、用户信息、配置开关；避免缓存大量原始数据或 Bitmap
- 对大对象做容量控制：如图片缓存设置 LRU 最大数量或总大小上限，超限时自动驱逐
借助工具验证与监控
人工审查易遗漏，尤其在多人协作或迭代频繁的项目中。必须引入自动化手段提前发现隐患。
- 静态检查：用
LeakCanary在 debug 包中自动检测 Activity/Fragment 泄漏，支持自定义观察点 - 堆快照分析：在怀疑泄漏时导出 hprof 文件，用 MAT 查看单例实例的支配树（Dominator Tree），确认它是否意外引用了 Activity 实例
- JVM 参数辅助：启动时添加
-XX:+HeapDumpOnOutOfMemoryError，OOM 时自动生成堆转储，便于回溯根因
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
