How to prevent memory leaks when we are using events? (Part 1)
Posted by Svetlin Ralchev on January 21, 2010
In the average development lifecycle is possible that event handlers that are attached to events of sources to not be destroyed in coordination with the listener object that attached the handler to the source. Hence, this can lead to memory leaks. This cause the developers to take care about memory management not only when they use unmanaged resources but also when they attach new event handlers to specified event.
This problem is scaled, when Microsoft ships Windows Presentation Foundation due to the lifecycle of visual element in the framework. They addressed this issue with implementation of Weak Event Design Pattern.
But what should do if we are not using WPF? After my research regarding the pattern I realised that we need something which is more simple than porting or implementing the weak event pattern. My idea is to use Weak Reference object as host of each event that I want to be automatically memory managed by the GC. This may be easily achieved by generic class that will wraps event handler and make it possible to be used the same as event handlers are used. But unfortunately it could not be used in case of wrapping delegate, because GC will collect it on next collection. This happens, because nobody keeps reference to the method delegate.
Design
Lets create a generic class WeakEventHandler<TEventArgs>, which can received as type parameter only arguments inherited from EventArgs class. We will have 3 methods (for subscribe, unsubscribe and raise event). To make the class to look more natively as the trivial EventHandler<TEventArgs> we will create also operators +/- with EventHandler<TEventArgs> object.
As you can see the overridden operators +/- are very useful. It looks like that you are using normal event handler. You should create the weak event handler as private field and expose it as public event property. This achieves that the user (the programmer that use your API) thinks that he is using a normal event.
Conclusion
Weak References gives a very flexible mechanism for memory management, which allows the Garbage Collector to collect all objects that have been subscribed for specified event and are not used anymore and not referenced by anybody. But they still don’t resolve the issue, because the delegate is collected on the next Garbage Collection.
References
After I created this article I searched in Google, regarding this approach and found several guys that has the similar or same ideas it before me. You may check their articles and approaches:
Note: I edited the article, because I don’t want to give a wrong example of using WeakReference class. See Part 2, where the right usage will be shown. In the first version I did a little joke to provoke people to write. Thanks to Beat Keiner that found what is wrong 
