警惕C#事件使用过程中的GC陷阱

关于C#中的事件，园里已经有大量的文章对其内在实现做过剖析，如果还不甚了解的可以阅读这篇文章

通过Demo来细看C#事件的内在机制

虽然比较早，但非常清楚地展示了事件的内部机制，总结一下就是

1、事件在被编译后生成了一个事件对应类型的私有委托，以及对应的_add方法和_remove方法用于该私有委托的注册和取消注册，其实就是平时常用的“+=”和“-=”。正是由于这个原因，所以事件在外部只能通过_add和_remove来对其调用链进行修改，而不能直接使用“=”，这使得事件的封装性要优于委托（理论上特别符合观察者模式）。

2、当我们通过_add和_remove来订阅事件和取消订阅的时候，最终改变的是生成的私有委托，而改变所使用的方法就是System.Delegate的Combine()。当事件第一次被订阅时，会将null和被订阅的方法进行Comine，然后将返回值赋值给私有委托。在之后事件被订阅的时候，会将原有的委托和新的方法进行Combine，然后将返回值赋给原委托。（这里非常像使用+对字符串进行拼接）

根据这个机制，不难想到一个问题，既然事件的订阅和取消最终采用的是Combine方法，而Combine方法又是通过生成新的委托然后返回的方式来实现的，如果事件的订阅者很多很多，又或者订阅和取消操作进行得非常频繁，是不是会影响到GC？答案是肯定的。

我做了一个简单的测试

像上面这样的代码，Test方法中的GC达到了0.5m，虽然像这样的代码比较极端，但也充分说明了，如果一个事件被频繁的订阅和取消，这里面产生的GC绝对是不容忽视的。就如同大家都知道不要大量和频繁地使用“+”来拼接字符串一样，对于事件，在订阅列表会频繁变化的时候，建议可以通过自行封装一个委托列表来达到和事件类似的效果，通过列表的Add和Remove来添加和去除委托，那样产生的GC基本就可以忽略不计了。