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.
Subscribe