一. 問題引入

通常，一個(gè)C語言學(xué)習(xí)者登堂入室的標(biāo)志就是學(xué)會(huì)使用了指針，而成為高手的標(biāo)志又是“玩轉(zhuǎn)指針”。指針是如此奇妙，通過一個(gè)地址，可以指向一個(gè)數(shù)，結(jié)構(gòu)體，對(duì)象，甚至函數(shù)。最后的一種函數(shù)，我們稱之為“函數(shù)指針”（和“指針函數(shù)”可不一樣?。┚拖袢缦碌拇a：

int func(int x); /* 聲明一個(gè)函數(shù) */ 
    int (*f) (int x); /* 聲明一個(gè)函數(shù)指針 */ 
   f=func; /* 將func函數(shù)的首地址賦給指針f */ 

C語言因?yàn)楹瘮?shù)指針獲得了極強(qiáng)的動(dòng)態(tài)性，因?yàn)槟憧梢酝ㄟ^給函數(shù)指針賦值并動(dòng)態(tài)改變其行為，我曾在單片機(jī)上寫的一個(gè)小系統(tǒng)中，任務(wù)調(diào)度機(jī)制玩的就是函數(shù)指針。

在.NET時(shí)代，函數(shù)指針有了更安全更優(yōu)雅的包裝，就是委托。而事件，則是為了限制委托靈活性引入的新“委托”（之所以為什么限制，后面會(huì)談到）。同樣，熟練掌握委托和事件，也是C#登堂入室的標(biāo)志。有了事件，大大簡化了編程，類庫變得前所未有的開放，消息傳遞變得更加簡單，任何熟悉事件的人一定都深有體會(huì)。

但你也知道，指針強(qiáng)大，高性能，帶來的就是危險(xiǎn)，你不知道這個(gè)指針是否安全，出了問題，非常難于調(diào)試。事件和委托這么好，可是當(dāng)你寫了很多代碼，完成大型系統(tǒng)時(shí)，心里是不是總覺得怪怪的？有當(dāng)年使用指針時(shí)類似的感覺？

如果是的話，請(qǐng)看如下的問題：

1.若多次添加同一個(gè)事件處理函數(shù)時(shí)，觸發(fā)時(shí)處理函數(shù)是否也會(huì)多次觸發(fā)？

2.若添加了一個(gè)事件處理函數(shù)，卻執(zhí)行了兩次或多次”取消事件“，是否會(huì)報(bào)錯(cuò)？

3.如何認(rèn)定兩個(gè)事件處理函數(shù)是一樣的？ 如果是匿名函數(shù)呢？

4.如果不手動(dòng)刪除事件函數(shù)，系統(tǒng)會(huì)幫我們回收嗎？

5.在多線程環(huán)境下，掛接事件時(shí)和對(duì)象創(chuàng)建所在的線程不同，那事件處理函數(shù)中的代碼將在哪個(gè)線程中執(zhí)行？

6.當(dāng)代碼的層次復(fù)雜時(shí)，開放委托和事件是不是會(huì)帶來更大的麻煩？

列下這些問題，下面就讓我們討論這些”尖酸刻薄“的問題。

#p#

二. 事件訂閱和取消問題

我們考慮一個(gè)典型的例子：加熱器，加熱器內(nèi)部加熱，在達(dá)到溫度后通知外界”加熱已經(jīng)完成“。 嘗試寫下如下測(cè)試類：

///   
   /// 熱水器  
   ///   
   public class Heater  
   {  
       public event EventHandler OnBoiled;  
       private  void RasieBoiledEvent()  
       {  
           if(OnBoiled==null)  
           {  
               Console.WriteLine("加熱完成處理訂閱事件為空");  
           }  
           else 
           {  
               OnBoiled(this, new EventArgs());  
           }  
       }  
       private Thread heatThread;  
       public void Begin()  
       {  
           heatTime = 5;  
           heatThread = new Thread(new ThreadStart(Heat));  
           heatThread.Start();  
           Console.WriteLine("加熱器已經(jīng)開啟", heatTime);  
   
       }  
       private int heatTime;  
       private void Heat()  
       {  
           while (true)  
           {  
               Console.WriteLine("加熱還需{0}秒", heatTime);  
   
               if (heatTime == 0)  
               {  
                   RasieBoiledEvent();  
                    return;  
               }  
               heatTime--;  
               Thread.Sleep(1000);  
   
           }  
       }  
   } 

OK,簡單了，下面是main函數(shù)：

class Program  
    {  
        static void Main(string[] args)  
        {  
            var test = new Heater();  
            test.OnBoiled += TestOnBoiled;  
            test.OnBoiled += TestOnBoiled;  
            test.Begin();  
            Console.ReadKey();  
        }  
        static void TestOnBoiled(object sender, EventArgs e)  
        {  
            Console.WriteLine("Hello事件被調(diào)用");  
        }  
    } 

我們有意將事件掛載了兩次，看看執(zhí)行效果:

很明顯，如果多次掛載同一事件處理函數(shù)，函數(shù)將會(huì)執(zhí)行多次。

這就是第一個(gè)問題的答案。

接下來，我們將上文中main函數(shù)中紅色代碼替換成如下蛋疼的代碼：  
test.OnBoiled += TestOnBoiled;  
test.OnBoiled -= TestOnBoiled;  
test.OnBoiled -= TestOnBoiled; 

在實(shí)際開發(fā)中，這種情況是很普遍的，誰都有可能取消訂閱多次，結(jié)果如何呢？

在執(zhí)行過程中，刪除兩次事件沒有報(bào)錯(cuò)，但當(dāng)觸發(fā)事件時(shí)，由于事件訂閱列表為空，所以，第二個(gè)問題的答案：多次刪除同一事件是不會(huì)報(bào)錯(cuò)的，即使事件只被訂閱了一次。若出現(xiàn)訂閱三次，取消訂閱兩次時(shí)，依舊執(zhí)行一次。

這個(gè)事情是好理解的，事件列表，實(shí)際上就是List，最簡單的增刪問題。

#p#

三. 有了匿名函數(shù)后？

自從學(xué)習(xí)匿名函數(shù)后，筆者就特別喜歡用它，除非代碼量特別長，否則十行之內(nèi)的事件訂閱，我都會(huì)用匿名函數(shù)。可是事情變得有意思了，寫了匿名函數(shù)后，幾乎沒人記得取消訂閱，那么，發(fā)生了什么事情呢？

和上次一樣，我們將前面紅色代碼改成下面的樣子:

test.OnBoiled += (s, e) => Console.WriteLine("加熱完成事件被調(diào)用");test.OnBoiled -= (s, e) => Console.WriteLine("加熱完成事件被調(diào)用");test.Bein(); 

Resharper直接給我畫了灰線，如下圖：

我估計(jì)情況不太樂觀，執(zhí)行之后：

果然！加熱完成事件還是被調(diào)用了，也就是說，看著形式完全一致的兩個(gè)匿名函數(shù)，編譯器生成的方法簽名是不一致的，根本就是兩個(gè)不同的函數(shù)。因此，匿名函數(shù)完全沒法取消訂閱！ 這是第三個(gè)問題的答案。

事件不能被取消訂閱！這下可慘了，我真的要取消怎么辦？沒辦法，只能乖乖的寫完整的事件函數(shù)。匿名方法雖好，千萬別用過頭。

但是，真正麻煩的問題來了，一個(gè)復(fù)雜的動(dòng)態(tài)系統(tǒng)中，一定隨時(shí)會(huì)有大量的對(duì)象生成和銷毀，你也一定會(huì)給它訂閱一些事件，當(dāng)你用匿名函數(shù)后，這些函數(shù)是不是就像死神一樣，一直掐著你的脖子？ 如果事件處理函數(shù)涉及重要操作，比如給對(duì)方付款，執(zhí)行多次你是不是就要哭死了？

#p#

四. 垃圾回收和事件

垃圾回收機(jī)制攙和進(jìn)來后，故事變的更有意思了。

我“殷切”的希望，垃圾回收器會(huì)幫我解決第三節(jié)最后一段談到的問題，幫我收拾掉那些函數(shù)，那真實(shí)的情況呢？我們做個(gè)試驗(yàn)：

同樣的，替換掉紅色部分：

test.OnBoiled += (s, e) => Console.WriteLine("加熱完成事件被調(diào)用");  
test=new Heater();  
GC.Collect();  //強(qiáng)制垃圾回收實(shí)際上可有可無  
test.Bein(); 

下面是執(zhí)行結(jié)果：

哈，起碼在我更新了對(duì)象引用，new了新對(duì)象之后，原來的匿名事件確實(shí)沒有了?？磥砭幾g器還是夠意思的。

可是，多數(shù)實(shí)際開發(fā)情況中，我們很少直接new一個(gè)對(duì)象覆蓋掉原來的引用。而是重新new了一個(gè)對(duì)象出來。這種情況的代碼如下

test.OnBoiled += (s, e) => Console.WriteLine("加熱完成事件被調(diào)用");  
            var heaters = new List() { test, test };  
            heaters.Clear();  
            test.Begin();  
            test = null;  
            GC.Collect(); 

執(zhí)行結(jié)果如下圖：

這種情況下，test即使被賦值為null，事件還是會(huì)乖乖執(zhí)行，因?yàn)槭悄涿瘮?shù)，你也沒法取消訂閱，而GC強(qiáng)制收集也沒用！ 這就是我們真實(shí)場(chǎng)景中最可怕的事情，你認(rèn)為它已經(jīng)消失了，可是它還掛在事件上！

其實(shí)這里有個(gè)破綻：Heater類里開了線程，我即使賦值為null，線程肯定還沒有被銷毀，事件確實(shí)可能會(huì)執(zhí)行，時(shí)間所限，我沒有嘗試在寫一個(gè)類測(cè)試不開線程的情況，有興趣的讀者可以幫忙試一試。

而且，經(jīng)過我查閱資料，當(dāng)你的對(duì)象訂閱了外部的事件，而又沒有取消訂閱，那么該對(duì)象是不會(huì)被GC回收的！這會(huì)造成很恐怖的問題，產(chǎn)生了幾千萬個(gè)對(duì)象沒法被回收。可是，匿名函數(shù)讓我怎么么取消訂閱？！

所以我們得到了結(jié)論，除非確實(shí)是一般場(chǎng)景，比如界面開發(fā)的window，生成了一直存在，或者在應(yīng)用程序關(guān)閉時(shí)回收，否則少用匿名函數(shù)吧！記得取消事件訂閱！否則會(huì)是非常麻煩的事情！

#p#

五.高潮： 多線程和事件

多線程本來就是程序員頭疼的問題，筆者在多線程知識(shí)上只是入門，沒開發(fā)過高并發(fā)系統(tǒng)，倒是經(jīng)常用并行庫加速算法執(zhí)行。 讓我們看看多線程和事件兩個(gè)最難搞的東西糾纏在一起時(shí)是個(gè)什么樣子。

一種常見的場(chǎng)景，是事件處理很耗時(shí)，比如執(zhí)行長時(shí)間的IO操作，或者進(jìn)行了復(fù)雜的數(shù)學(xué)計(jì)算，我們不想影響主線程，那么你想當(dāng)然的會(huì)通過多線程的方法解決。

創(chuàng)建對(duì)象的線程，一般是主線程（或者UI線程），那么，怎么讓事件處理函數(shù)在另外一個(gè)線程執(zhí)行呢？ 你真的保證處理函數(shù)在另外一個(gè)線程中執(zhí)行了？異步調(diào)用？好辦法，不過我們此處不說這個(gè)。

//////////////////**************///////////////////////////

修正：經(jīng)過了重新的測(cè)試，發(fā)現(xiàn)我的測(cè)試用例寫的有問題，為了讓Heater類自己觸發(fā)事件，我在內(nèi)部寫了一個(gè)新線程，導(dǎo)致測(cè)試不準(zhǔn)確。

結(jié)論應(yīng)該是： 不論是不是在多線程環(huán)境下，事件處理函數(shù)一定在觸發(fā)事件位置所在的線程中，和事件訂閱者的創(chuàng)建線程，訂閱事件時(shí)所在的線程無關(guān)。。。。。。我第五節(jié)的內(nèi)容，有多半都是錯(cuò)的。。。。

因此，若是觸發(fā)事件所在線程是主線程的話，基本上只能用我提出的第二種做法，通過事件內(nèi)部使用線程池來執(zhí)行了。感謝 West Continent 的討論。

/////////////////*************/////////////////////

1. 新建線程方法：

初學(xué)者會(huì)這么做：

test.OnBoiled += (s, e) =>  
                {  
                    var newThread = new Thread(  
                        new ThreadStart(  
                            () =>  
                                {  
                             Thread.Sleep(2000); //模擬長時(shí)間操作  
                                    Console.WriteLine("總算把熱好的水加到了暖瓶里");  
                                }));  
                    newThread.Start();  
                };             
            test.Begin(); 

我的手指還是選擇了匿名函數(shù)，用起來真爽，這種情況下，顯然事件處理函數(shù)所在線程和主線程不一樣。

可是，稍微有點(diǎn)基礎(chǔ)的人就知道，當(dāng)事件被頻繁觸發(fā)時(shí)，線程就會(huì)被頻繁生成，線程同樣是非常昂貴的系統(tǒng)資源，更何況，線程的啟動(dòng)時(shí)間是不確定的，可能會(huì)耽誤大事。這不是個(gè)好方案。

2. 線程池

采用.NET 4.0的線程池試試看，代碼如下：

var mainThread = Thread.CurrentThread;  
            test.OnBoiled += (s, e) =>  
                {  
                    ThreadPool.QueueUserWorkItem((d) =>  
                        {  
                            Thread.Sleep(2000); //模擬長時(shí)間操作  
                            Console.WriteLine("總算把熱好的水加到了暖瓶里");  
                            if (Thread.CurrentThread != mainThread)  
                            {  
                                Console.WriteLine("兩者執(zhí)行的是不同的線程");  
                            }  
                            else 
                            {  
                                Console.WriteLine("兩者執(zhí)行的是相同的線程");  
                            }  
                        });  
                };  
            test.Begin(); 

我們通過緩存主線程，并比較處理函數(shù)中的線程，得到結(jié)果如下：

確實(shí)，采用線程池時(shí)，會(huì)是兩個(gè)是不一樣的線程，線程池由于內(nèi)部做了管理，因此可以有效的利用線程，避免瘋狂新開線程造成的嚴(yán)重的性能問題。

可是，我覺得還是麻煩，尤其是有多種事件時(shí)，挨個(gè)寫線程池還是太麻煩了。那么，我們是不是有兩種方案？

一種是將構(gòu)造函數(shù)寫在一個(gè)新線程中，另外一種是將事件訂閱函數(shù)寫在新線程中，兩者會(huì)發(fā)生怎樣的情況呢？

3. 對(duì)象的構(gòu)造函數(shù)處在新線程時(shí)：

如下測(cè)試代碼：

var mainThread = Thread.CurrentThread;  
            var autoResetEvent = new AutoResetEvent(false);  //通過信號(hào)機(jī)制保證對(duì)象首先被創(chuàng)建  
            ThreadPool.QueueUserWorkItem((d) =>  
                {  
                    test=new Heater();  
                    autoResetEvent.Set();  
                });  
            autoResetEvent.WaitOne();  
            test.OnBoiled += (s, e) => Console.WriteLine(Thread.CurrentThread != mainThread ? "兩者執(zhí)行的是不同的線程" : "兩者執(zhí)行的是相同的線程");  
            test.Begin(); 

代碼值得一提的是，為了保證對(duì)象被首先創(chuàng)建，采用了信號(hào)機(jī)制實(shí)現(xiàn)線程同步，當(dāng)創(chuàng)建后，主線程才會(huì)往下執(zhí)行，否則會(huì)拋出空引用的異常.

結(jié)果如下：

可見： 主線程稱為Main, 若對(duì)象構(gòu)造函數(shù)在B線程執(zhí)行，事件不在主線程中執(zhí)行。那是不是在B線程中執(zhí)行呢？暫時(shí)還不知道。

4. 對(duì)象的事件訂閱函數(shù)處在新線程時(shí)：

在另外一個(gè)線程里創(chuàng)建對(duì)象是更麻煩的，你要解決線程同步問題，惡心不，哈哈。

那么，若訂閱事件的代碼在線程B時(shí)，情況是怎樣的呢?

var mainThread = Thread.CurrentThread;   
            ThreadPool.QueueUserWorkItem((d) =>  
                {  
                    var bThread = Thread.CurrentThread;  
                    test.OnBoiled += (s, e) =>  
                        {  
                            if(Thread.CurrentThread == mainThread )  
                                Console.WriteLine("事件在主線程中執(zhí)行");  
                            else if (bThread==Thread.CurrentThread)  
                            {  
                                Console.WriteLine("事件在訂閱事件的線程B中執(zhí)行");  
                            }  
                            else 
                            {  
                                Console.WriteLine("事件在第三個(gè)線程中執(zhí)行");  
                            }  
                        };  
                });  
   
            test.Begin(); 

結(jié)論：

說實(shí)話，我看到這個(gè)場(chǎng)景的時(shí)候大吃一驚，居然執(zhí)行事件的代碼不在主線程，不在訂閱事件的線程，而在另外一個(gè)第三者線程！這可能就是線程池的無敵之處吧，它連事件訂閱函數(shù)都給托管了！真是碉堡了??！

不過，管它是什么線程里執(zhí)行，反正我主線程是不會(huì)被堵塞了，哈哈.

六.結(jié)語

本來想今天把最后一個(gè)問題都解決的，可是時(shí)間實(shí)在太晚，而且文章已經(jīng)夠長了。不妨最后一個(gè)問題，“在復(fù)雜軟件環(huán)境下，如何理性正確的使用委托和事件”放在第二部分吧。有些問題我也沒搞清，在做實(shí)驗(yàn)的情況下，才逐漸接近結(jié)論。 寫完這篇文章，我深有收獲。

其實(shí)，按照慣例，應(yīng)該把IL代碼好好搞出來給大家看才算是“專業(yè)”的選擇，不過我確實(shí)不懂IL，就不拿出來丟人了，高手們請(qǐng)自行腦補(bǔ)。

本文介紹了C#的委托和事件的訂閱和取消訂閱，并在匿名函數(shù)和多線程兩個(gè)環(huán)境下討論了一些問題。如果你覺得這篇文章對(duì)你有幫助，請(qǐng)點(diǎn)一下推薦，若有任何問題，歡迎留言討論，共同學(xué)習(xí)。

測(cè)試代碼見附件，請(qǐng)將不同Region的代碼解開注釋進(jìn)行測(cè)試。

原文鏈接：http://www.cnblogs.com/buptzym/archive/2013/03/15/2962300.html