RxJava中Single/Completable订阅终止后是否会引发内存泄漏

核心结论前置 #

你的理解在标准无异常的冷流场景下基本成立，但存在几个容易踩坑的例外场景，不能一概而论。 #

订阅终止后的内存留存逻辑 #

首先纠正一个广泛传播的认知偏差：

不是所有RxJava流都必须手动调用dispose()才能释放引用。

Single、Completable、Maybe这类单次终端型流的设计逻辑就是：当onSuccess/onError/onComplete这类终端回调执行完成后，流会自动断开上下游的引用链，不会主动持有订阅链路中的对象引用。
这和无限发射的冷Observable、热Observable（比如点击事件、位置监听流）有本质区别：后者不会自动触发终端事件，会一直持有订阅者引用，必须手动dispose才能释放。

但这个自动释放逻辑有个大前提：流链路中没有全局/长生命周期对象主动持有订阅相关引用。如果你的自定义操作符、RxJava全局插件、静态缓存对象主动存了订阅实例或者流对象，哪怕流已经终止，引用也不会被释放，这属于代码实现问题，和流类型本身的特性无关。 #

Android场景下持有Activity引用的泄漏判定 #

你提到的「仅在流发射前产生临时泄漏，终止后引用随订阅回收、无持续性泄漏」的判断，在以下前提都满足时是成立的：

• 你使用的是标准冷流，没有加cache()、replay()这类会缓存结果、持有下游引用的操作符
• 流最终能正常走到终端回调，没有因为线程死锁、异常被吞等问题永远挂起
• 订阅链路中没有其他长生命周期对象（单例SDK、全局广播、静态变量）主动持有Observer或者回调实例

如果以上前提不满足，就可能产生持续性泄漏，常见的触发场景包括：

• 给流加了cache()、replay()这类缓存操作符，同时流实例被ViewModel单例、静态变量等长生命周期对象持有，哪怕流已经终止，操作符内部缓存的链路引用也不会释放
• 流执行时异常被全局错误处理器捕获，而你的全局错误逻辑里持有了Activity引用
• 自定义Observer/Lambda隐式持有Activity引用，同时这个Observer被注册到了全局SDK、系统服务中，流终止时没有自动反注册

另外要注意：哪怕只有临时泄漏，也可能引发实际问题。比如你在Single里做耗时10s的网络请求，Activity里持有几MB的Bitmap，这10s内Activity完全无法被GC回收，如果内存紧张很容易触发OOM。 #

实操建议 #

• 不要因为Single/Completable会自动终止就完全放弃生命周期绑定：Android场景下最好还是绑定Activity/Fragment的生命周期，在页面销毁时自动dispose，缩短临时泄漏的时间窗口
• 订阅回调里尽量不要直接持有Activity/View的强引用，确实需要使用时优先用弱引用包装，或者提前把页面销毁后不需要的参数提前提取出来
• 不要在单例、Application级别的长生命周期对象里创建持有Activity、View等短生命周期Context引用的流实例

内容的提问来源于stack exchange，提问作者detcle