.Net WInform开发笔记(五)关于事件Event

我前面几篇博客中提到过.net中的事件与windows事件的区别，本文讨论的是前者，也就是我们代码中经常用到的event。event很常见，button控件的click、keypress等等，picturebox控件的paint等等都属于本文讨论范畴，本文会例举出有关“事件编程”的几种方法，还会提及由“事件编程”引起的memoryleak（跟“内存泄露”差不多），以及由“事件编程”引起的一些异常。

引子：
.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<object,delegate>_handlerlist=newdictionary<object,delegate>();
staticobject_xx1_key=newobject();
staticobject_xx2_key=newobject();
staticobject_xxn_key=newobject();
//事件
publiceventeventhandlerxx1
{
add
{
if(_handlerlist.containskey(_xx1_key))
{
_handlerlist[_xx1_key]=delegate.combine(_handlerlist[_xx1_key],value);
}
else
{
_handlerlist.add(_xx1_key,value);
}
}
remove
{
if(_handlerlist.containskey(_xx1_key))
{
_handlerlist[_xx1_key]=delegate.remove(_handlerlist[_xx1_key],value);
}
}
}
publiceventeventhandlerxx2
{
add
{
if(_handlerlist.containskey(_xx2_key))
{
_handlerlist[_xx2_key]=delegate.combine(_handlerlist[_xx2_key],value);
}
else
{
_handlerlist.add(_xx2_key,value);
}
}
remove
{
if(_handlerlist.containskey(_xx2_key))
{
_handlerlist[_xx2_key]=delegate.remove(_handlerlist[_xx2_key],value);
}
}
}
publiceventeventhandlerxxn
{
add
{
if(_handlerlist.containskey(_xxn_key))
{
_handlerlist[_xxn_key]=delegate.combine(_handlerlist[_xxn_key],value);
}
else
{
_handlerlist.add(_xxn_key,value);
}
}
remove
{
if(_handlerlist.containskey(_xxn_key))
{
_handlerlist[_xxn_key]=delegate.remove(_handlerlist[_xxn_key],value);
}
}
}
protectedvirtualvoidonxx1(eventargse)
{
if(_handlerlist.containskey(_xx1_key))
{
eventhandlerhandler=_handlerlist[_xx1_key]aseventhandler;
if(handler!=null)
{
handler(this,e);
}
}
}
protectedvirtualvoidonxx2(eventargse)
{
if(_handlerlist.containskey(_xx2_key))
{
eventhandlerhandler=_handlerlist[_xx2_key]aseventhandler;
if(handler!=null)
{
handler(this,e);
}
}
}
protectedvirtualvoidonxxn(eventargse)
{
if(_handlerlist.containskey(_xxn_key))
{
eventhandlerhandler=_handlerlist[_xxn_key]aseventhandler;
if(handler!=null)
{
handler(this,e);
}
}
}
publicvoiddosomething()
{
//符合某一条件
onxx1(neweventargs());
onxx2(neweventargs());
onxxn(neweventargs());
}
}

存放事件委托链表的容器为dictionary<object,delegate>类型，该容器存放各个委托链表的表头，每当有一个“事件注册”的动作发生时，先查找字典中是否有表头，如果有，直接加到表头后面；如果没有，向字典中新加一个表头。“事件注销”操作类似。

 
字典的作用是将每个委托链表的表头组织起来，便于查询访问。可能有人已经看出来修改后的代码并没有考虑“线程安全”问题，的确，引进了集合去管理委托链表之后，再也没办法解决“线程安全”而又不影响效率了，因为现在各个事件不再是独立存在的，它们都放在了同一集合。另外，集合dictionary<object,delegate>声明为protected，子类完全可以使用该集合对子类的事件委托链表进行管理。
注：上图中委托链中各节点引用的都是实例方法，没有列举静态方法。
其实，.net中所有从system.windows.forms.control类继承下来的类，都是用这种方式去维护事件委托链表的，只不过它不是用的字典（我只是用字典模拟），它使用一个eventhandlerlist类对象来存储所有的委托链表表头，作用跟dictionary<object,delegate>差不多，并且，.net中也没去处理“线程安全”问题。总之，clr在处理“线程安全”问题做得不是足够好，当然，一般事件编程也基本用在单线程中（比如winform中的ui线程中），打个比方，在ui线程中创建的control（或其派生类），基本上都在同一线程中访问它，基本不涉及跨线程去访问control（或其派生类），所以大可不必担心事件编程中遇到“线程安全”问题。

事件编程中的内存泄露
说到“内存泄露”，可能很多人认为这不应该是.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~。

跟之前一样，代码未调试运行，可能有错误。