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 shocould be garbage collected.

An article in codeprojectProvides varous 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 callDispose.

 

2. Use an event wrapper.

This solution moves the event handling code into a wrapper class that forwards the callto 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, usingWeakEventManagerClass. It works similar to the previous wrapper solutions, doesn't that a singleWeakEventManagerInstance serves as a wrapper between multiple sender and multiple listeners. Due to this single instance,WeakEventManagerCan avoid the leak when the event is never called: registering another event onWeakEventManagerCan 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,WeakEventManagerHas 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-DisciplesHolds 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 shoshould 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:

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

 

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

 

Recruitment Advertisement, taofu Information Technology and wangxin hengtian both recruit. NET senior developers and architects. You need to have a deep understanding of. NET and object-oriented design and good English reading and writing capabilities. If you have experience in developing WPF or Silverlight, you can work in Hangzhou. Send your resume to nxu [at] statestreet [dot] com.