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(

                masterCollection_CollectionChanged);

    }

 

    void masterCollection_CollectionChanged(object sender,

        NotifyCollectionChangedEventArgs e)

    {

        // Update view

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

            _name,

            Program.MASTER_COLLECTION.Count);

    }

 

    ~View()

    {

        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

        GC.Collect();

        GC.WaitForPendingFinalizers();

 

        // 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

        GC.Collect();

        GC.WaitForPendingFinalizers();

 

        Console.WriteLine("Example finished.");

        Console.ReadLine();

    }

 

 

    static void Main(string[] args)

    {

        Program p = new Program();

        p.Run();

    }

}

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: ,

.NET-Basics

Comments are closed

Powered by BlogEngine.NET 1.5.0.7
Theme by Mads Kristensen

About the author

Chad

Meeeee!!!

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

Calendar

<<  April 2014  >>
MoTuWeThFrSaSu
31123456
78910111213
14151617181920
21222324252627
2829301234
567891011

View posts in large calendar