Events and Memory Leaks in .NET

Question

I'm using C# .NET 3.5 ... and I've been working to decouple a BLL object by moving database related activity into a seperate worker object. The worker object adds entities to the database and events a success or failure message back to a BLL object.

When I instance the worker object in the BLL I wire up the worker's events and set the BLL's event handler using the event += delegate(eventhandler) syntax.

I've heard that if I don't explicitly unwire the listeners with the -= syntax when the worker is disposed that there is a potential for memory leaks.

All of this processing occurs in a windows service that picks up messages from a queue and calls the appropriate BLL object ... I'm worried that I might be introduce a memory leak into this process.

Answer 1

If you only ever subscribe to the event once in your service, you should be fine.

Answer 2

Subscribing to an event adds a reference from the subscriber to the provider.

x.Event += y.handler means that x now holds a reference to y

If x has a longer lifespan than y then y cannot be garbage collected until all references to x have disappeared.

In your case you are listening to events from the workers in the BLL (if I understand you correctly) then you have references to the workers remaining in the BLL unless you explicity unsubscribe.

However, if you are finishing with the worker at the same time as the BLL then it won't actually matter.

Answer 3

What you heard is true. As long as your object is subscribed to an event from another reachable object, the runtime will not release the subscriber object. If your application creates one or a small set of worker objects at the beginning for its lifetime, then you should be OK. If the application creates a worker object for each BLL object but the reference to BLL instance is released, you should be OK too.

The dangerous thing is to blindly subscribe an instance method to a static event or an instance event of an object with a long lifetime.

Answer 4

Look into using a .NET background worker or thread pool and the synchronization mechanisms available with those solutions.