Memory leak caused by EventHandle - weak event

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:

代码

private   void  HookCommand(ICommand command)
{
    EventHandler handler  =   new  EventHandler( this .OnCanExecuteChanged);
    CanExecuteChangedHandler.SetValue( this , handler);
    command.CanExecuteChanged  +=  handler;
     this .UpdateCanExecute();
}

 

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

 

招聘广告，道富信息科技和网新恒天都招聘.NET高级开发人员和架构师。需要对.NET和面向对象设计有比较深入的了解和较好的英文读写能力，如果有 WPF 或Silverlight开发经验更佳，工作地点杭州。简历请发至 nxu  [at] statestreet [dot] com。