Shawn Van ness has an excellent article, that spells out how event listeners can cause memory leaks, yep even when running in managed code. Steve Main sums it up pretty well:
The main issue is the “lapsed listener” problem. This occurs when objects subscribe to events and subsequently get out of scope. The problem is that the event subscriber doesn’t get garbage collected because the event is still holding a reference to it inside of the event’s invocation list. The event subscriber is still considered reachable from the GC’s point of view. As such, it doesn’t get collected until the event goes out of scope (which is usually at application shutdown) which means that the event subscriber is effectively “leaked”.
Moral of the story: when you implement an Observer pattern, it’s important to consider the relative lifetime of events and subscribers. If implemented naively, you’ll end up having objects that live a lot longer than you think they should. Unsubscribe() is your friend.
As Fabrice writes, .NET’s delegates and events are implementations of the Observer Design Pattern . But the current problem is one more reminder that Design Patterns should not be applied blindly.
If you write the following code, you’ll see that the object instance gets correctly released and collected:
GC.Collect();
GC.WaitForPendingFinalizers();
Subject subject = new Subject();
subject.SomethingHappened += new EventHandler(observer.subject_SomethingHappened);
GC.Collect();
GC.WaitForPendingFinalizers();
Guys from around the community came with various solutions. They call them Weak Delegates. Follow the links to learn more:
- Greg Schechter (real case study; schema’s will help you to understand the problem)
- Ian Griffiths and Xavier Musy (extensions and improvements)
More Information:
