使用Rx.NET的FromEventPattern订阅事件是否需要担心内存泄漏问题？

不管是原生C#事件，还是Rx.NET基于FromEventPattern封装的事件桥接，内存泄漏的触发逻辑从来没有本质变化：长期存活的发布者对象，持有了短生命周期订阅者的强引用，导致订阅者失去所有外部引用后，仍然被发布者的事件列表拴住，无法被GC回收。
Rx.NET并没有设计“自动解决所有事件退订问题”的魔法，它做的只是把原生事件的退订流程，封装成了更统一的IDisposable句柄操作，下面拆解两种常见实现的实际引用关系和泄漏风险。

两种Rx.NET实现的泄漏风险拆解 #

1. 实体层预定义事件可观察序列的实现 #

也就是在EntityModel构造函数里提前初始化PropChangedObservable的写法，实际引用链路是这样的：

• PropChangedObservable是和EntityModel实例生命周期绑定的序列。当第一个订阅者调用它的Subscribe方法时，序列才会执行你传入的事件挂接逻辑，把一个内部桥接器委托注册到EntityModel自身的PropertyChanged事件列表上。
• 这个桥接器会维护所有订阅者的回调列表，当事件触发时，把参数转成EventPattern格式分发给所有订阅者。
• 这里的泄漏风险分两种场景：
  • 如果EntityModel本身是短生命周期对象（比如和对应的WindowVm同生死），哪怕你完全不处理订阅返回的IDisposable句柄，也不会产生泄漏——当EntityModel被GC回收时，它持有的桥接器委托、桥接器里维护的所有订阅回调都会跟着一起被回收，没有残留引用。
  • 如果EntityModel是长期存活对象（比如全局单例、长期缓存的业务实体），当WindowVm订阅后不主动Dispose订阅句柄，桥接器会一直持有WindowVm传入的回调（也就是那个捕获了WindowVm实例的lambda）的强引用，最终导致WindowVm无法被回收，泄漏逻辑和原生手写事件完全一致。

2. 订阅端临时创建可观察序列的实现 #

也就是在WindowVm的Subscribe方法里当场写FromEventPattern的写法，实际引用链路是这样的：

• 每次调用Subscribe方法，都会生成一个全新的独立序列。当执行序列的Subscribe操作时，会立刻执行你传入的事件挂接回调，把这个序列专属的桥接器委托注册到MyModel的PropertyChanged事件列表上。
• 你拿到的IDisposable句柄，本质就是封装了“把这个专属桥接器委托从MyModel的事件列表里移除”的操作，执行Dispose后，桥接器自己持有的所有回调引用会全部释放。
• 这个写法不存在任何自动清理逻辑：如果你完全不持有这个IDisposable、也不主动调用Dispose，那么MyModel的事件列表会一直持有这个桥接器的强引用，桥接器又持有捕获了WindowVm的lambda回调的强引用，100%会产生内存泄漏——和你用原生事件执行MyModel.PropertyChanged += DoSomething之后，永远不执行-= DoSomething的效果完全没有区别。

实践中的判断标准 #

你可以直接套用下面的规则判断要不要手动处理退订：

• 只要事件发布者的生命周期长于订阅者的生命周期，就必须主动Dispose订阅返回的IDisposable——不管是原生事件还是Rx序列，都逃不开这个规则。
• 当事件发布者的生命周期短于或等于订阅者的生命周期时，即使不主动Dispose，也不会产生持久泄漏：发布者被回收时，所有关联的事件引用、桥接器引用都会跟着被GC清理。
• Rx.NET相比原生事件的优势只是统一了退订的操作接口：你可以用CompositeDisposable把页面/ViewModel里的所有订阅句柄统一管理，在ViewModel销毁的位置一次性全部Dispose，比手写逐个-= 委托的方式少很多漏写的概率，但本质上并没有消灭退订的要求。

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