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
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.
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.
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:
EventHandler handler = new EventHandler(this.OnCanExecuteChanged);
command.CanExecuteChanged += handler;
Delay's blog talks about how to use SOS and gcroot to diagnose memory leak.
招聘广告，道富信息科技和网新恒天都招聘.NET高级开发人员和架构师。需要对.NET和面向对象设计有比较深入的了解和较好的英文读写能力，如果有 WPF 或Silverlight开发经验更佳，工作地点杭州。简历请发至 nxu [at] statestreet [dot] com。