享受代碼,享受人生

When using normal C# events, registering an event handler creates a strong reference from the event source to the listening object.

If the source object has a longer lifetime than the listener, and the listener doesn't need the events anymore when there are no other references to it, using normal .NET events causes a memory leak: the source object holds listener objects in memory that should be garbage collected.

An article in codeproject provides various patterns for resolving the memory leak caused eventhandle.

1.　　Dispose pattern. Unhook the event handler in dispose method.

Disadvantages: Explicit memory management is hard, code can forget to call Dispose.

 

2. 　  Use an event wrapper.

This solution moves the event handling code into a wrapper class that forwards the calls to a listener instance which is referenced with a weak reference. This weak reference allows for easy detection if the listener is still alive.

Disadvantages : Leaks the wrapper instance when the event never fires.

 

3.      WPF WeakEventManager.

WPF has built-in support for listener-side weak events, using the WeakEventManager class. It works similar to the previous wrapper solutions, except that a single WeakEventManager instance serves as a wrapper between multiple sender and multiple listeners. Due to this single instance, the WeakEventManager can avoid the leak when the event is never called: registering another event on a WeakEventManager can trigger a clean-up of old events. These clean-ups are scheduled using the WPF dispatcher, they will occur only on threads running a WPF message loop. 

Also, the WeakEventManager has a restriction that our previous solutions didn't have: it requires the sender parameter to be set correctly, otherwise the source cannot be found in the listener's code.

Disadvantages: Tied to a WPF dispatcher, cannot be easily used on non-UI-threads.

 

 

A long thread in WPF-Disciples holds a discussion on a potential bug in RelayCommand. Nathan Nesbit though WPF’s CanExecuteChanged Implementation was Wrong.

 

The RelayCommand directly registers the CanExecuteChanged event handler with the CommandManager.RequestSuggested event.  The MSDN docs say that the CommandManager.RequestSuggested only holds a weak reference to the handler, so shouldn't the RelayCommand also keep a strong reference to the delegate to avoid it being collected?   

 

The answer is that we should either keep a strong reference to the delegate on Command Source or Listener. WPF keeps the delegate on Command Source which are Button, MenuItem and etc.

Check out the second line of HookCommand method which defined in ButtonBase:

 

Delay's blog talks about how to use SOS and gcroot to diagnose memory leak.

 

招聘廣告，道富信息科技和網新恒天都招聘.NET高級開發人員和架構師。需要對.NET和面向對象設計有比較深入的了解和較好的英文讀寫能力，如果有 WPF 或Silverlight開發經驗更佳，工作地點杭州。簡歷請發至 nxu  [at] statestreet [dot] com。