Event Handler Memory Leaks

by Chad 9. February 2010 06:18

Event handlers are a common cause of memory leaks in managed applications. It’s so easy to register an event handler, that sometimes we can forget what’s actually happening. There are three parties involved in eventing: the event source, a delegate, and the event sink.

The event source is the object that publishes notifications via an event. The event sink is the object that is interested in those notifications and knows how to respond to the event. The delegate is the object that enables the event source to communicate with the event sink.

Looking at the System.Delegateclass, we see that it has two properties: Target and Method. Target contains a reference to the event sink object and Method contains a MethodInfo object used to invoke the event handler method on the event sink object. When you use the C# statement eventSource.SomeEvent += new EventHandler(eventSink.SomeEventHandler); you are creating a new delegate with a reference to your event sink object and adding a reference to the delegate class to the event source object. The references look like this: event source > delegate > event sink.

The effect of this isn’t very visible when the lifetime of the event source and event sink are similar. However, when the event source lives much longer, say for the lifetime of the application, and the event sink only has a short lifetime, you can quickly leak memory because the event source will never release it’s reference to the event sink.

Consider this example

class View


    private string _name;

    public View(string name)


        _name = name;


        // Register for CollectionChanged notifications; MASTER_COLLECTION

        // is static.

        Program.MASTER_COLLECTION.CollectionChanged +=

            new NotifyCollectionChangedEventHandler(




    void masterCollection_CollectionChanged(object sender,

        NotifyCollectionChangedEventArgs e)


        // Update view

        Console.WriteLine("{0}: {1} items.",







        Console.WriteLine("View {0} Finalized.", _name);




class Program


    public static readonly ObservableCollection<object> MASTER_COLLECTION

        = new ObservableCollection<object>();


    public void Run()


        // Create two views

        View v1 = new View("v1");

        View v2 = new View("v2");


        // Raise CollectionChanged event

        MASTER_COLLECTION.Add(new object());


        // Release v1 & v2 references

        v1 = null;

        v2 = null;


        // Wait for Garbage collector to release memory




        // Create v3

        View v3 = new View("v3");


        // Raise CollectionChanged event

        Console.WriteLine("We only expect v3 to be in memory.");

        MASTER_COLLECTION.Add(new object());

        v3 = null;


        // Wait for Garbage collector to release memory




        Console.WriteLine("Example finished.");





    static void Main(string[] args)


        Program p = new Program();




The output for this is:

v1: 1 items.
v2: 1 items.
We only expect v3 to be in memory.
v1: 2 items.
v2: 2 items.
v3: 2 items.
Example finished.
View v3 Finalized.
View v1 Finalized.
View v2 Finalized.

How to avoid this?
You need to keep this subtle problem in mind when designing your classes. To prevent these types of memory leaks, you’ll need to design mechanisms into your object’s lifecycle so that it can detach it’s event handlers. Detaching an event handler is as simple as using the –= operator. The difficult part is knowing when to detach. You can use the IDisposable pattern or expose a CleanUp() method or add lifecycle events to trigger the detach.

Tags: ,


Comments are closed

Powered by BlogEngine.NET
Theme by Mads Kristensen

About the author



Hi, my name is Chad Boschert and I'm a software developer in Springfield, Missouri. I've been developing .NET applications in C# since 2002.

Recent Comments

Comment RSS


<<  April 2014  >>

View posts in large calendar