這篇文章主要介紹了C#編程中.NET的弱事件模式,深入討論了C#中相關的垃圾回收機制,需要的朋友可以參考下

引言

你可能知道，事件處理是內存泄漏的一個常見來源，它由不再使用的對象存留產生，你也許認為它們應該已經被回收了，但不是，并有充分的理由。

在這個短文中(期望如此)，我會在 .Net 框架的上下文事件處理中展示這個問題，之后我會教你這個問題的標準解決方案，弱事件模式。有兩種方法，即：

“傳統”方法 (嗯，在 .Net 4.5 前，所以也沒那么老)，它實現起來比較繁瑣

.Net 4.5 框架提供的新方法，它則是盡其可能的簡單

(源代碼在這里可供使用。)

從常見事物開始

在一頭扎進本文核心內容前，讓我們回顧一下在代碼中最常使用的兩個事物：類和方法。

事件源

讓我為您介紹一個基本但很有用的事件源類，它最低限度地揭示了足夠的復雜性來說明這一點：

1. public class EventSource 
2. { 
3. public event EventHandlerEvent = delegate { }; 
4.  
5. public void Raise() 
6. { 
7. Event(this, EventArgs.Empty); 
8. } 
9. } 

對好奇那個奇怪的空委托初始化方法(delegate { })的人來說，這是一個用來確保事件總被初始化的技巧，這樣就可以不必每次在使用它之前都要檢查它是否不為NULL。

觸發垃圾收集的實用方法

在.net中，垃圾收集以一種不確定的方式觸發。這對我們的實驗很不利，我們的實驗需要以一種確定的方式跟蹤對象的狀態。

所以，我們必須定期觸發自己的垃圾收集操作，同時避免復制管道代碼，管道代碼已經在在一個特定的方法中釋放：

1. static void TriggerGC() 
2. { 
3. Console.WriteLine("Starting GC."); 
4.  
5. GC.Collect(); 
6. GC.WaitForPendingFinalizers(); 
7. GC.Collect(); 
8.  
9. Console.WriteLine("GC finished."); 
10. } 

雖然不是很復雜，但是如果你不是很熟悉這種模式，還是有必要小小解釋一下：

第一個 GC.Collect() 觸發.net的CLR垃圾收集器，對于負責清理不再使用的對象，和那些類中沒有終結器(即c#中的析構函數)的對象，CLR垃圾收集器足夠勝任

GC.WaitForPendingFinalizers() 等待其他對象的終結器執行;我們需要這樣做，因為，你將看到我們使用終結器方法去追蹤我們的對象在什么時候被收集的

第二個GC.Collect() 確保新生成的對象也被清理了

引入問題

首先讓我們試著通過一些理論，最重要的是還有一個演示的幫助，去了解事件監聽器有哪些問題。

背景

一個對象要想被作為事件偵聽器，需要將其實例方法之一登記為另一個能夠產生事件的對象(即事件源)的事件處理程序，事件源必須保持一個到事件偵聽器對象的引用，以便在事件發生時調用此偵聽器的處理方法。

這很合理，但如果這個引用是一個 強引用，則偵聽器會作為事件源的一個依賴 從而不能作為垃圾回收，即使引用它的最后一個對象是事件源。

下面詳細圖解在這下面發生了什么：

事件處理問題

這將不是一個問題，如果你可以控制listener object的生命周期，你可以取消對事件源的訂閱當當你不再需要listener,常常可以使用disposable pattern(用后就扔的模式)。

但是如果你不能在listener生命周期內驗證單點響應，在確定性的方式中你不能把它處理掉，你必須依賴GC處理...這將從不會考慮你所準備的對象，只要事件源還存在著!

例子

理論都是好的，但還是讓我們看看問題和真正的代碼。

這是我們勇敢的時間監聽器，還有點幼稚，我們很快知道為什么:

1. public class NaiveEventListener 
2. { 
3. private void OnEvent(object source, EventArgs args) 
4. { 
5. Console.WriteLine("EventListener received event."); 
6. } 
7.  
8. public NaiveEventListener(EventSource source) 
9. { 
10. source.Event += OnEvent; 
11. } 
12.  
13. ~NaiveEventListener() 
14. { 
15. Console.WriteLine("NaiveEventListener finalized."); 
16. } 
17. } 

用一個簡單例子來看看怎么實現運作:

1. Console.WriteLine("=== Naive listener (bad) ==="); 
2.  
3. EventSource source = new EventSource(); 
4.  
5. NaiveEventListener listener = new NaiveEventListener(source); 
6.  
7. source.Raise(); 
8.  
9. Console.WriteLine("Setting listener to null."); 
10. listener = null; 
11.  
12. TriggerGC(); 
13.  
14. source.Raise(); 
15.  
16. Console.WriteLine("Setting source to null."); 
17. source = null; 
18.  
19. TriggerGC(); 

輸出:

1. EventListener received event. 
2. Setting listener to null. 
3. Starting GC. 
4. GC finished. 
5. EventListener received event. 
6. Setting source to null. 
7. Starting GC. 
8. NaiveEventListener finalized. 
9. GC finished. 

讓我們分析下這個運作流程:

“EventListener received event.“:這是我們調用 “source.Raise()”的結果; perfect, seems like we're listening.

“Setting listener to null.“: 我們把本地事件監聽器對象引用賦空值，這樣應該可以讓垃圾回收器回收了.

“Starting GC.“: 垃圾回收開始.

“GC finished.“: 垃圾回收開始， 但是 但是我們的事件監聽器沒有被回收器回收, 這樣就證明了事件監聽器的析構函數沒有被調用。

“EventListener received event.“: 第二次調用 “source.Raise()”來確認,發現這監聽器還活著。

“Setting source to null.“: 我們在賦空值給事件的原對象.

“Starting GC.“: 第二次垃圾回收.

“NaiveEventListener finalized.“: 這一次幼稚的事件監聽終于被回收了，遲到總好過沒有.

“GC finished.“:第二次垃圾回收完成.

結論：確實有一個隱藏的對事件監聽器的強引用，目的是防止它在事件源被回收之前被回收!

希望有針對此問題的標準解決方案：讓事件源可以通過弱引用來引用偵聽器，在事件源存在時也可以回收偵聽器對象。

這里有一個標準的模式及其在.NET框架上的實現：弱事件模式(http://msdn.microsoft.com/en-us/library/aa970850.aspx)。 And there is a standard pattern and its implementation in the .Net framework: the weak event pattern.

弱事件模式

讓我們看看在.NET中如何應付這個問題，

通常有超過一種方法去做，但是在這種情況下可以直接決定：

如果你正在使用 .Net 4.5 ，那么你將從簡單的實現受益

另外，你必須依靠一點人為的技巧手段

傳統方式

WeakEventManager 是所有模式管道的封裝

IWeakEventListener 是管道，它允許一個組件連接到WeakEventManager管件

(這兩個位于WindowBase程序集，你將需要參考你自己的如果你不在開發WPF項目，你應該準確的參考WindowBase)

因此這有兩步處理.

首先通過繼承WeakEventManager來實現一個自定義事件管理器:

重寫 StartListening 和 StopListening 方法，分別注冊一個新的handler和注銷一個已存在的; 它們將被WeakEventManager基類使用。

提供兩個方法來訪問listener列表, 命名為 “AddListener” 和 “RemoveListener “，給自定義事件管理器的使用者使用。

通過在自定義事件管理器上暴露一個靜態屬性，提供一個方式去獲得當前線程的事件管理器。

之后使listenr實現IWeakEventListenr接口:

實現 ReceiveWeakEvent 方法

嘗試去處理這個事件

如果無誤的處理好事件，將返回true

有很多要說的，但是可以相對地轉換成一些代碼:

首先是自定義弱事件管理器:

1. public class EventManager : WeakEventManager 
2. { 
3. private static EventManager CurrentManager 
4. { 
5. get 
6. { 
7. EventManager manager = (EventManager)GetCurrentManager(typeof(EventManager)); 
8.  
9. if (manager == null) 
10. { 
11. manager = new EventManager(); 
12. SetCurrentManager(typeof(EventManager), manager); 
13. } 
14.  
15. return manager; 
16. } 
17. } 
18.  
19.  
20. public static void AddListener(EventSource source, IWeakEventListener listener) 
21. { 
22. CurrentManager.ProtectedAddListener(source, listener); 
23. } 
24.  
25. public static void RemoveListener(EventSource source, IWeakEventListener listener) 
26. { 
27. CurrentManager.ProtectedRemoveListener(source, listener); 
28. } 
29.  
30. protected override void StartListening(object source) 
31. { 
32. ((EventSource)source).Event += DeliverEvent; 
33. } 
34.  
35. protected override void StopListening(object source) 
36. { 
37. ((EventSource)source).Event -= DeliverEvent; 
38. } 
39. } 

之后是事件listener:

1. public class LegacyWeakEventListener : IWeakEventListener 
2. { 
3. private void OnEvent(object source, EventArgs args) 
4. { 
5. Console.WriteLine("LegacyWeakEventListener received event."); 
6. } 
7.  
8. public LegacyWeakEventListener(EventSource source) 
9. { 
10. EventManager.AddListener(source, this); 
11. } 
12.  
13. public bool ReceiveWeakEvent(Type managerType, object sender, EventArgs e) 
14. { 
15. OnEvent(sender, e); 
16.  
17. return true; 
18. } 
19.  
20. ~LegacyWeakEventListener() 
21. { 
22. Console.WriteLine("LegacyWeakEventListener finalized."); 
23. } 
24. } 

檢查下:

1. Console.WriteLine("=== Legacy weak listener (better) ==="); 
2.  
3. EventSource source = new EventSource(); 
4.  
5. LegacyWeakEventListener listener = new LegacyWeakEventListener(source); 
6.  
7. source.Raise(); 
8.  
9. Console.WriteLine("Setting listener to null."); 
10. listener = null; 
11.  
12. TriggerGC(); 
13.  
14. source.Raise(); 
15.  
16. Console.WriteLine("Setting source to null."); 
17. source = null; 
18.  
19. TriggerGC(); 

輸出:

1. LegacyWeakEventListener received event. 
2. Setting listener to null. 
3. Starting GC. 
4. LegacyWeakEventListener finalized. 
5. GC finished. 
6. Setting source to null. 
7. Starting GC. 
8. GC finished. 

非常好，它起作用了，我們的事件listener對象現在可以在第一次GC里正確的析構，即使事件源對象還存活，不再泄露內存了.

但是要寫一堆代碼就為了一個簡單的listener，想象一下你有一堆這樣的listener，你必須要為每個類型的寫一個弱事件管理器!

如果你很擅長代碼重構，你可以發現一個聰明的方式去重構所有通用的代碼.

在.Net 4.5 出現之前，你必須自己實現弱事件管理器，但是現在，.Net提供一個標準的解決方案來解決這個問題了，現在就來回顧下吧!

.Net 4.5 方式

.Net 4.5 已介紹了一個新的泛型版本的遺留WeakEventManager: WeakEventManager.

(這個類可以在WindowsBase集合.)

多虧了 .Net WeakEventManager 自己處理泛型, 不用去一個個實現新事件管理器.

而且代碼還簡單和可讀:

1. public class WeakEventListener 
2. { 
3. private void OnEvent(object source, EventArgs args) 
4. { 
5. Console.WriteLine("WeakEventListener received event."); 
6. } 
7.  
8. public WeakEventListener(EventSource source) 
9. { 
10. WeakEventManager.AddHandler(source, "Event", OnEvent); 
11. } 
12.  
13. ~WeakEventListener() 
14. { 
15. Console.WriteLine("WeakEventListener finalized."); 
16. } 
17. } 

簡單的一行代碼，真簡潔.

其他實現的使用也是相似的, 就是裝入所有東西到事件listener類里:

1. Console.WriteLine("=== .Net 4.5 weak listener (best) ==="); 
2.  
3. EventSource source = new EventSource(); 
4.  
5. WeakEventListener listener = new WeakEventListener(source); 
6.  
7. source.Raise(); 
8.  
9. Console.WriteLine("Setting listener to null."); 
10. listener = null; 
11.  
12. TriggerGC(); 
13.  
14. source.Raise(); 
15.  
16. Console.WriteLine("Setting source to null."); 
17. source = null; 
18.  
19. TriggerGC(); 

輸出也是肯定正確的:

1. WeakEventListener received event. 
2. Setting listener to null. 
3. Starting GC. 
4. WeakEventListener finalized. 
5. GC finished. 
6. Setting source to null. 
7. Starting GC. 
8. GC finished. 

預期結果也跟之前一樣，還有什么問題?!

結論

正如你看到的，在.Net上實現弱事件模式 是十分直接, 特別在 .Net 4.5.

如果你沒有用.Net 4.5來實現，將需要一堆代碼, 你可能不去用任何模式而是直接使用C# (+= and -=), 看看是否有內存問題，如果注意到泄露，還需要花必要的時間去實現一個。

但是用 .Net 4.5, 它是自由和簡潔，而且由框架管理, 你可以毫無顧慮的選擇它, 盡管沒有 C# 語法 “+=” 和 “-=” 的酷， 但是語義是清晰的，這才是最重要的.