引子:
.net中事件最常用在“观察者”设计模式中,事件的发布者(subject)定义一个事件,事件的观察者(observer)注册这个事件,当发布者激发该事件时,所有的观察者就会响应该事件(表现为调用各自的事件处理程序)。知道这个逻辑过程后,我们可以写出以下代码:
ViewCode
ClassSubject
{
publiceventXXEventHandlerXX;
protectedvirtualvoidOnXX(XXEventArgse)
{
If(XX!=null)
{
XX(this,e);
}
}
publicvoidDoSomething()
{
//符合某一条件
OnXX(newXXEventArgs());
}
}
delegatevoidXXEventHandler(objectsender,XXEventArgse);
ClassXXEventArgs:EventArgs
{
}
以上就是一个最最原始的含有事件类的定义。外部对象可以注册Subject对象的XX事件,当某一条件满足时,Subject对象就会激发XX事件,所以观察者作出响应。
注:编码中请按照标准的命名方式,事件名、事件参数名、虚方法名、参数名等等,标准请参考微软。
事件观察者注册事件代码为:
ViewCode
Subjectsub=newSubject();
Sub.XX+=newXXEventHandler(sub_XX);
voidsub_XX(objectsender,XXEventArgse)
{
//dosomething
}
以上是一个最简单的“事件编程”结构代码,其余所有的写法都是从以上扩展出来的,基本原理不变。
升级:
在定义事件变量时,有时候我们可以这样写:
ViewCode
ClassSubject
{
privateXXEventHandler_xx;
publiceventXXEventHandlerXX
{
add
{
_xx=(XXEventHandler)Delegate.Combine(_xx,value);
}
remove
{
_xx=(XXEventHandler)Delegate.Remove(_xx,value);
}
}
protectedvirtualvoidOnXX(XXEventArgse)
{
if(_xx!=null)
{
_xx(this,e);
}
}
publicvoidDoSomething()
{
//符合某一条件
OnXX(newXXEventArgs());
}
}
其余代码跟之前一样,升级后的代码显示的实现了“add/remove”,显示实现“add/remove”的好处网上很多人都说可以在注册事件之前添加额外的逻辑,这个就像“属性”和“字段”的关系,
ViewCode
publiceventXXEventHandlerXX
{
add
{
//添加逻辑
_xx=(XXEventHandler)Delegate.Combine(_xx,value);
}
remove
{
//添加逻辑
_xx=(XXEventHandler)Delegate.Remove(_xx,value);
}
}
没错,确实与“属性(Property)”的作用差不多,但它不止这一个好处,我们知道(不知道的上网看看),在多线程编程中,很重要的一点就是要保证对象“线程安全”,因为多线程同时访问同一资源时,会出现预想不到的结果。当然,在“事件编程”中也要考虑多线程的情况。“引子”部分代码经过编译器编译后,确实可以解决多线程问题,但是存在问题,它经过编译后:
ViewCode
publiceventXXEventHandlerXX;
//该行代码编译后类似如下:
privateXXEventHandler_xx;
[MethodImpl(MethodImplOptions.Synchronized)]
publicvoidadd_XX(XXEventHandlerhandler)
{
_xx=(XXEventHandler)Delegate.Combine(_xx,handler);
}
[MethodImpl(MethodImplOptions.Synchronized)]
publicvoidremove_XX(XXEventHandlerhandler)
{
_xx=(XXEventHandler)Delegate.Remove(_xx,handler);
}
以上转换为编译器自动完成,事件(取消)注册(+=、-=)间接转换由add_XX和remove_XX代劳,通过在add_XX方法和remove_XX方法前面添加类似[MethodImpl(MethodImplOptions.Synchronized)]声明,表明该方法为同步方法,也就是说多线程访问同一Subject对象时,同时只能有一个线程访问add_XX或者是remove_XX,这就确保了不可能同时存在两个线程操作_xx这个委托链表,也就不可能发生不可预测结果。那么,[MethodImpl(MethodImplOptions.Synchronized)]是怎么做到线程同步的呢?其实查看IL语言,我们不难发现,[MethodImpl(MethodImplOptions.Synchronized)]的作用类似于下:
ViewCode
ClassSubject
{
privateXXEventHandler_xx;
publicvoidadd_XX(XXEventHandlerhandler)
{
lock(this)
{
_xx=(XXEventHandler)Delegate.Combine(_xx,handler);
}
}
publicvoidremove_XX(XXEventHandlerhandler)
{
lock(this)
{
_xx=(XXEventHandler)Delegate.Remove(_xx,handler);
}
}
}
如我们所见,它就相当于给自己加了一个同步锁,lock(this),我不知道诸位在使用同步锁的时候有没有刻意去避免lock(this)这种,我要说的是,使用这种同步锁要谨慎。 原因至少两个:
1)将自己(Subject对象)作为锁定目标的话,客户端代码中很可能仍以自己为目标使用同步锁,造成死锁现象。因为this是暴露给所有人的,包括代码使用者。
ViewCode
privatevoidDoWork(Subjectsub)//客户端代码
{
lock(sub)//客户端代码锁定sub对象
{
sub.XX+=newXXEventHandler(…);//嵌套锁定同一目标
//sub.add_XX(newXXEventHandler(…));相当于调用add_XX,出现死锁
//
//
//
//dootherthing
}
}
2)当Subject类包含多个事件,XX1、XX2、XX3、XX4…时,每注册(或取消)一个事件时,都需要锁定同一目标(Subject对象),这完全没必要。因为不同的事件有不同的委托链表,多个线程完全可以同时访问不同的委托链表。然而,编译器还是这样做了。
ViewCode
ClassSubject
{
privateXXEventHandler_xx1
privateEventHandler_xx2;
publicvoidadd_XX1(XXEventHandlerhandler)
{
lock(this)
{
_xx1=(XXEventHandler)Delegate.Combine(_xx1,handler);
}
}
publicvoidremove_XX1(XXEventHandlerhandler)
{
lock(this)
{
_xx1=(XXEventHandler)Delegate.Remove(_xx1,handler);
}
}
publicvoidadd_XX2(EventHandlerhandler)
{
lock(this)
{
_xx2=(EventHandler)Delegate.Combine(_xx2,handler);
}
}
publicvoidremove_XX2(EventHandlerhandler)
{
lock(this)
{
_xx2=(EventHandler)Delegate.Remove(_xx2,handler);
}
}
}
在一个线程中执行sub.XX1+=newXXEventHandler(…)(间接调用sub.add_XX1(newXXEventHandler(…)))的时候,完全可以在另一线程中同时执行sub.XX2+=newEventHandler(…)(间接调用sub.add_XX2(newEventHandler(…)))。_xx1和_xx2两个没有任何联系,访问他们更不需要线程同步。如果这样做了,影响性能效率(编译器自动转换成的代码就是这样子)。
结合以上两点,可以将“升级”部分代码修改为以下,从而可以很好的解决“线程安全”问题而且不会像编译器自动转换的代码那样影响效率:
ViewCode
ClassSubject
{
privateXXEventHandler_xx;
privateobject_xxSync=newobject();
publiceventXXEventHandlerXX
{
add
{
lock(_xxSync)
{
_xx=(XXEventHandler)Delegate.Combine(_xx,value);
}
}
remove
{
lock(_xxSync)
{
_xx=(XXEventHandler)Delegate.Remove(_xx,value);
}
}
}
protectedvirtualvoidOnXX(XXEventArgse)
{
if(_xx!=null)
{
_xx(this,e);
}
}
publicvoidDoSomething()
{
//符合某一条件
OnXX(newXXEventArgs());
}
}
在Subject类中增加一个同步锁目标“_xxSync”,不再以对象本身为同步锁目标,这样_xxSync只在类内部可见(客户端代码不可使用该对象作为同步锁目标),不会出现死锁现象。另外,如果Subject有多个事件,那么我们可以完全增加多个类似“_xxSync”这样的东西,比如“_xx1Sync、_xx2Sync…”等等,每个同步锁目标之间没有任何关联。
当一个类(比如前面提到的Subject)中包含的事件增多时,几十个甚至几百个,而且派生类还会增加事件,在这种情况下,我们需要统一管理这些事件,由一个集合来统一管理这些事件是个不错的选择,比如:
ViewCode
ClassSubject
{
protectedDictionary
存放事件委托链表的容器为Dictionary
字典的作用是将每个委托链表的表头组织起来,便于查询访问。可能有人已经看出来修改后的代码并没有考虑“线程安全”问题,的确,引进了集合去管理委托链表之后,再也没办法解决“线程安全”而又不影响效率了,因为现在各个事件不再是独立存在的,它们都放在了同一集合。另外,集合Dictionary
注:上图中委托链中各节点引用的都是实例方法,没有列举静态方法。
其实,.net中所有从System.Windows.Forms.Control类继承下来的类,都是用这种方式去维护事件委托链表的,只不过它不是用的字典(我只是用字典模拟),它使用一个EventHandlerList类对象来存储所有的委托链表表头,作用跟Dictionary
事件编程中的内存泄露
说到“内存泄露”,可能很多人认为这不应该是.net讨论的问题,因为GC自动回收内存,不需要编程的人去管理内存,其实不然。凡是发生了不能及时释放内存的情况,都可以叫“内存泄露”,.net中包括“托管内存”也包括“非托管内存”,前者由GC管理,后者必然由编程者考虑了(类似C++中的内存),这里我们讨论的是前者,也就是托管内存的泄露。
我们知道(假设诸位都知道),当一个托管堆中的对象不可达时,也就是程序中没有对该对象有引用时,该对象所占堆内存就属于GC回收的范围了。可是,如果编程者认为一个对象生命期应该结束(该对象不再使用)的时候,同时也理所当然地认为GC会回收该对象在堆中占用的内存时,情况往往不是TA所认为的那样,应为很有可能(概率很大),该对象在其他的地方仍然被引用,而且该引用相对来说不会很明显,我们叫这个为“隐式强引用”(Implicitstrongreference),而对于ClassA=newClass();这样的代码,A就是“显示强引用”(Explicitstrongreference)了。(至于什么是强引用什么是弱引用,这个在这里我就不说了)那么,不管是“显示强引用”还是“隐式强引用”都属于“强引用”,一个对象有一个强引用存在的话,GC就不会对它进行内存回收。
事件编程中,经常会产生“隐式强引用”,参考前面的“图1”中委托链表中的每个节点都包含一个target,当一个事件观察者向发布者注册一个事件时,那么,发布者就会保持一个观察者的强引用,这个强引用不是很明显,因此我们称之为隐式强引用。因此,当观察者被编程者理所当然地认为生命期结束了,再没有任何对它的引用存在时,事件发布者却依然保持了一个强引用。如下图:
尽管有时候,Observer生命期结束(我们理所当然地那样认为),Subject(发布者)却依旧对Observer有一个强引用(strongreference)(图2中红色箭头),该引用称作为“隐式强引用”。GC不会对Observer进行内存回收,因为还有强引用存在。如果Observer为大对象,且系统存在很多这样的Observer,当系统运行时间足够长,托管堆中的“僵尸对象”(有些对象虽然已经没有使用价值了,但是程序中依旧存在对它的强引用)越来越多,总有一个时刻,内存不足,程序崩溃。
事件编程中引起的异常
其实还是因为我们的Observer注册了事件,但在Observer生命期结束(编程者认为的)时,释放了一些必备资源,但是Subject还是对Observer有一个强引用,当事件发生后,Subject还是会通知Observer,如果Observer在处理事件的时候,也就是事件处理程序中用到了之前已经释放了的“必备资源”,程序就会出错。导致这个异常的原因就是,编程者以为对象已经死了,将其资源释放,但对象本质上还未死去,仍然会处理它注册过的事件。
ViewCode
//Form1.cs中:
privatevoidform1_Load(objectsender,EventArgse)
{
Form2form2=newForm2();
form2.Click+=newEventHandler(form2_Click);
form2.Show();
}
privatevoidform2_Click(objectsender,EventArgse)
{
this.Show();
}
form1为Observer,form2为Subject,form1监听form2的Click事件,在事件处理程序中将自己Show出来,一切运行良好,但是,当form1关闭后,再次点击form2激发Click事件时,程序报错,提示form1已经disposed。原因就是我们关闭form1时,认为form1生命期已经结束了,事实上并非如此,form2中还有对form1的引用,当事件发生后,还是会通知form1,调用form1的事件处理程序(form2_Click),而碰巧的是,事件处理程序中调用了this.Show()方法,意思要将form1显示出来,可此时form1已经关闭了。
小结
不管是内存泄露还是引起的异常,都是因为我们注册了某些事件,在对象生命期结束时,没有及时将已注册的事件注销,告诉事件发布者“我已死,请将我的引用删除”。因此一个简单的方法就是在对象生命期结束时将所有的事件注销,但这个只对简单的代码结构有效,复杂的系统几乎无效,事件太多,根本无法记录已注册的事件,再者,你有时候根本不知道对象什么时候生命期结束。下次介绍利用弱引用概念(Weakreference)引申出来的弱委托(Weakdelegate),它能有效地解决事件编程中内存泄露问题。原理就是将图2中每个节点中的Target由原来的强引用(StrongReference)改为弱引用(WeakReference)。
希望有帮助O(∩_∩)O~。
跟之前一样,代码未调试运行,可能有错误。