单例模式因生命周期过长易引发内存泄漏。它用static字段持有实例，导致所引用的短命对象（如activity context、监听器）无法被gc回收，常见于误传context、强持回调或静态集合未清理，应改用application context、weakreference或weakhashmap并及时解绑。
单例模式本身不是问题，问题出在它“太长寿”——它的生命周期和整个应用一样长。一旦它无意中持有了短命对象的引用，那些本该被回收的对象就会一直卡在内存里，越积越多，最终可能触发 OOM。
单例的静态特性是根源
单例通常用 static 字段持有自身实例，JVM 加载类时就初始化，直到应用结束才释放。这意味着：它持有的任何引用，都会阻止对应对象被 GC 回收。
- 比如单例里存了一个 Activity 的 Context，Activity 销毁后，只要单例还活着，这个 Context 就无法释放
- 再比如缓存了监听器、回调接口或 Handler 实例，而这些对象又关联着 UI 组件，就会连带拖住整个视图树
常见误用场景
不是用了单例就会泄漏，而是使用方式不当才埋下隐患：
Java JDK 25
下载
Java JDK 25 来自 OpenJDK 官方归档，版本为 JDK 25，本条下载地址已指向官方 Windows x64 zip 安装包直链，适合调试旧项目或兼容旧版 Java 运行环境。
-
传入 Activity 或 Fragment 的 Context：应统一改用 Application Context（
getApplicationContext()） - 直接持有监听器或回调引用：可改用 WeakReference 包装，或在业务结束时主动 remove
- 在单例中维护静态集合（如 List、Map）并不断 add 对象：若不清理，集合会无限膨胀；可用 WeakHashMap 或定期清理策略
怎么验证和修复
泄漏发生时，往往表现为内存占用持续上升、GC 频繁但回收效果差。可用 Android Profiler 或 MAT 工具分析堆转储（heap dump），重点查看：
- 单例实例是否持有大量不该存在的对象引用
- 从单例到疑似泄漏对象之间是否存在强引用链（尤其是通过 context、listener、handler 等路径）
- 确认泄漏对象的 GC Roots 是否包含该单例
修复核心原则：单例只该持有真正需要长期存活的对象，所有临时性、界面相关、生命周期短的对象，必须避免强引用，或确保及时解绑。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
