views:

360

answers:

3

If my software has two object instances, one of which is subscribed to the events of the other. Do I need to unsubscribe them from one another before they are orphaned for them to be cleaned up by the garbage collector? Or is there any other reason why I should clear the event relationships? What if the subscribed to object is orphaned but the subscriber is not, or vise versa?

+6  A: 

Yes you do. The event listeners are holding references to the objects, and would prevent them from being garbage collected.

Let's look at an example to see what happens. We have to classes; one exposes an event, the other consumes it:

class ClassA
{
    public event EventHandler Test;
    ~ClassA()
    {
        Console.WriteLine("A being collected");
    }
}
class ClassB
{
    public ClassB(ClassA instance)
    {
        instance.Test += new EventHandler(instance_Test);
    }

    ~ClassB()
    {
        Console.WriteLine("B being collected");
    }

    void instance_Test(object sender, EventArgs e)
    {
        // this space is intentionally left blank
    }
}

Note how ClassB does not store a reference to the ClassA instance; it merely hooks up an event handler.

Now, let's see how the objects are collected. Scenario 1:

ClassB temp = new ClassB(new ClassA());
Console.WriteLine("Collect 1");
GC.Collect();
Console.ReadKey();
temp = null;
Console.WriteLine("Collect 2");
GC.Collect();
Console.ReadKey();

We create a ClassB instance and hold a reference to it through the temp variable. It gets passed a new instance of ClassA, where we do not store a reference to it anywhere, so it goes out of scope immediately after the ClassB constructor is done. We have the garbage collector run once when ClassA has gone out of scope, and once when ClassB as gone out of scope. The output:

Collect 1
A being collected
Collect 2
B being collected

Scenario 2:

ClassA temp = new ClassA();
ClassB temp2 = new ClassB(temp);
temp2 = null;
Console.WriteLine("Collect 1");
GC.Collect();
Console.ReadKey();
temp = null;
Console.WriteLine("Collect 2");
GC.Collect();
Console.ReadKey();

A new instance of ClassA is created and a reference to it is stored in the temp variable. Then a new instance of ClassB is created, getting the ClassA instance in temp passed to it, and we store a reference to it in temp2. Then we set temp2 to null, making the ClassB instance going out of scope. As before, we have the garbage collector run after each instance has gone out of scope. The output:

Collect 1
Collect 2
B being collected
A being collected

So, to conclude; if the instance that exposes an event goes out of scope, it becomes available for garbage collection, regardless of whether there are event handlers hooked up or not. If an instance that has an event handler hooked up to an event in another instance, it will not be available for garbage collection until either the event handler is detached, or the instance to which the event handler is attached becomes available for garbage collection.

Fredrik Mörk
+5  A: 

You only need to unhook events if the object exposing the events is long-lived, but the object hooking the event would otherwise be short-lived (and get garbage collected fairly quickly).

In this case, failing to unhook will cause what amounts to a memory leak, because your short-lived object will not be able to be GCed -- because the event in the long-lived object holds onto a delegate, which holds a reference to the short-lived object. Since the short-lived object is still referenced by that delegate, it can't get garbage-collected.

Static events are long-lived by definition -- they live until the program exits. If you hook a static event, you definitely should unhook it when you're done.

If both objects are about to be orphaned, unhooking isn't necessary.

Joe White
+5  A: 

Subscribing to an event results in a strong reference to the subscriber. This is because, under the covers, events are delegates, and delegates to instance methods are a combination of the object reference and the actual method. If you don't unsubscribe, the publisher will continue to maintain the references, and the subscribing objects never get truly orphaned (and GC'ed) as long as the publisher is alive.

The reverse isn't true i.e. the subscribed object doesn't have any reference to the publisher.

Senthil Kumar