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:

1
2
3

StoopidObject object = new StoopidObject();  
GC.Collect();  
GC.WaitForPendingFinalizers();

If you write the following code instead, although there is no apparent reference kept to the Observer, the Observer instance will not be released:

1
2
3
4
5

Observer observer = new Observer();  
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:

More Information: