欢迎您访问程序员文章站本站旨在为大家提供分享程序员计算机编程知识!
您现在的位置是: 首页  >  IT编程

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

程序员文章站 2022-07-30 14:46:37
关于C#中的事件,园里已经有大量的文章对其内在实现做过剖析,如果还不甚了解的可以阅读这篇文章 通过Demo来细看C#事件的内在机制 虽然比较早,但非常清楚地展示了事件的内部机制,总结一下就是 1、事件在被编译后生成了一个事件对应类型的私有委托,以及对应的_add方法和_remove方法用于该私有委托 ......

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

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

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

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

 

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

我做了一个简单的测试

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

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