And that is when problems might appear.  If you’re using Castle Windsor with the default ReleasePolicy (which is the LifecycledComponentsReleasePolicy) then each resolved transient instance will be stored in memory by that policy until the instance is explicitly released.  The benefit of this policy is that the container can automatically dispose any disposable transient dependency of a resolved component.  In my case, i’ve come to rely on that feature to achieve deterministic disposal behavior throughout my code base. 

Now, when you configure NServiceBus and pass it your instance of Castle Windsor, it obviously doesn’t change the ReleasePolicy like it does when it creates its own instance of Castle Windsor.   This is good because changing the policy of a passed in container would almost certainly have a huge behavioral implication for the application and such an action would be unacceptable when integrating a new framework into your project.   But since NServiceBus doesn’t have the notion of needing to release resolved components, every single transient instance it resolves through your container will be stored in memory until the application’s process is terminated.  Which means that you’ll leak instances of the following types for each message that your system needs to handle:

• NServiceBus.Grid.MessageHandlers.GridInterceptingMessageHandler
• NServiceBus.Sagas.Impl.SagaMessageHandler
• Your own MessageHandlers (and their transient dependencies as well)

If your MessageHandlers don’t have dependencies (highly unlikely if you’re already using an IOC container) then you’d still have 3 leaking instances per incoming message.  Add the number of transient dependencies of any handler to that and the number of leaking instances can increase dramatically.

First of all, if you do not depend on Windsor’s default ReleasePolicy’s behavior, then the easiest way to avoid this problem is definitely to set the container’s ReleasePolicy to the NoTrackingReleasePolicy like NServiceBus does itself when it’s configuring itself with a new instance of the container.

If you do depend on it, and you don’t want leaking instances that hang around forever, then the approach listed below is one way to solve this problem.  There are probably other solutions available, and while the approach listed below can definitely be considered to be a HACK, i do think it’s the best solution to this particular problem.

Because we don’t want to change anything about the way that we’re already using the container, we just need to make sure that NServiceBus’ usage of the container doesn’t conflict with ours.  That basically means that we need to make sure that the components that it resolves should not be tracked by the container.   There are 2 kinds of components that NServiceBus will resolve during normal operation:

1. Its own components that it needs to implement the features it offers you
2. Your message handlers that you need to handle incoming messages

The first category is easy to exclude from Windsor’s tracking behavior.  We can simply create our own ReleasePolicy which extends the default ReleasePolicy, and make sure that any instances of an NServiceBus-type are no longer tracked by the container:

Then you need to set this release policy somewhere in your application’s startup routine:

(in this case, IoC.Container returns an IWindsorContainer instance)

This will make sure that no instances of NServiceBus-types will ever leak in the container.  But now we still have to deal with our message handlers.  The solution to making sure they are not disposed is not the cleanest out there but hey, it works.  I basically introduced a base class that all my message handlers will need to inherit from, with the following implementation in the Handle method:

Uh oh… i just felt a great disturbance in the Force, as if tens of voices suddenly cried out in terror about my direct usage of the IoC container in a component!

Conceptually, this is wrong on many levels.  Then again, this makes sure that the message handlers (and their dependencies) that are resolved by NServiceBus will always be guaranteed to be released by the comtainer.  It might not be nice, but it avoids the memory leak and it doesn’t force me to change my other code.

And once NServiceBus is modified to release the components it resolves (if it’s ever modified that is…) i only need to get rid of my custom policy and the try/finally block.  Unfortunately, my existing message handlers will then all implement the Process method instead of the Handle method but that is quickly fixed with a simple rename-refactoring.

Even though this is a pretty big hack (IMHO), at least its impact on the code is minimal… it will be easy to get rid of once the real problem is solved in NSB, and there are no real downsides to this that i can think of at the moment.

and then this:

to make a problem go away.

Can you come up with a WHY comment? (the category of this post is another hint)

First of all, consider the following 2 classes:

Pretty simple… the Publisher publishes the MyEvent event, and the Subscriber subscribes to the event when an instance is created. As you should already know, whenever the publisher of an event has a longer lifecycle than its subscibers, subscribers must explicitly unsubscribe from the event to prevent instances of the subscribers to remain in memory instead of being garbage collected.

The following simple example illustrates the problem:

This will produce the following console output:

triggering event for the first time… both subscribers should respond
Instance 1 is handling event…
Instance 2 is handling event…
triggering event for the second time… hopefully, the first subscriber has been collected
Instance 1 is handling event…
Instance 2 is handling event…
triggering event for the third time… hopefully, both subscribers have been collected
Instance 1 is handling event…
Instance 2 is handling event…

Obviously, both subscriber instances remained in memory even though we no longer had references to those instances and they should’ve been collected by the garbage collector. For those of you who don’t know what’s going on: an event handler will internally keep a list of references to all the objects that subscribed to the event. This means that it is only normal that the Publisher is actually keeping all of the Subscriber instances ‘live’ because it keeps references to it. That means that the garbage collector will never collect these instances until the Producer is eligible for garbage collection.

Now, Fabrice’s proposed solution is to change the Producer to this:

Again, memory leaks through event subscription only occur when the publisher of an event lives longer than the subscribers of an event. Obviously, this solution will hardly help in the situation where the memory actually leaks, because the publisher will not be disposed of until it is no longer needed. Which means that the Producer will still keep all instances from no-longer-needed subscribers in memory.

The only way to avoid this problem is to explicitly unsubscribe each subscriber from the event. Which means that you should implement IDisposable on the Subscriber:

That’s not enough though… you need to explicitly dispose these instances as well. So the example code now looks like this:

And the output of this code is now correct:

triggering event for the first time… both subscribers should respond
Instance 1 is handling event…
Instance 2 is handling event…
triggering event for the second time… hopefully, the first subscriber has been collected
Instance 2 is handling event…
triggering event for the third time… hopefully, both subscribers have been collected

To summarize:

• If a producer will stay alive longer than the subscriber, then it will keep the subscribers in memory until the publisher gets garbage collected

• Your subscribers should explicitly unsubscribe from events from publishers, unless you know that the lifetime of both the subscriber or the publisher is either identical, or that the publisher has a shorter lifetime than the subscriber. You should preferably unsubscribe from these events in a Dispose method and your subscriber should implement IDisposable.

• Always call the Dispose method on subscribers that implement IDisposable. Otherwise, you’ll still leak instances of the subscribers.

I wrote a very simple Silverlight application which has a rather typical memory leak. Here’s the actual code:

For some of you, the memory leak is already very clear. Like i said, it’s a very simple example

Let’s go through the process of finding and fixing the memory leak using WinDbg. First of all, download Debugging Tools For Windows (which contains the WinDbg executable) here and install it.

Then we start our application in Internet Explorer (for some reason i can’t use WinDbg to inspect the managed memory heap with Firefox, so i just use Internet Explorer for this stuff) and use it. In the case of my example, that means clicking the button which creates a new view a couple of times.

Open WinDbg.exe and select the ‘Attach to a Process’ menu item in the ‘File’ menu and select the iexplore.exe process.

Then you need to load the correct version of sos.dll:

After that we can see which types of our MySilverlightApplication namespace are present in the managed heap, including how many instances of them:

As you can see, there are 13 instances of our MyView type present in the heap. Using the value in the MT column, we can drill down further:

This shows the memory address of each instance of the MyView type in the heap. Now we can see if there are any live references to these instances:

This is actually for the first address that was listed. As you can see, it is still a reachable reference, which means it will not be collected by the garbage collector. The chain of references clearly indicates that the instance is still referenced from our event in the MainPage instance. All of the previously listed instances show the same reference chain, so this is clearly a memory leak. Even though we should only have one active reference of MyView at any point in time of this application, the MyEvent event on MainPage clearly keeps each instance of MyView alive.

The correct way to fix this is to make sure that whenever we remove an instance of MyView, we need to unsubscribe it from the MainPage’s MyEvent handler. Always remember this rule when it comes to dealing with events: if the publisher of the event has a longer lifetime than the subscriber of the event, then you absolutely have to unsubscribe each subscriber from the event or the publisher will keep references to each subscriber (preventing them from being garbage collected) for as long as the publisher is alive.

Here’s the modified version of the above code which avoids the memory leak:

Let’s see if this really fixed the memory leak. If we fire up the application and press the button a couple of times, the application should normally only have one live reference of MyView in memory.

I clicked the button 5 times, and the above output shows that there are 5 instances of MyView on the heap. So did we fix the leak or not? Check the output below:

As you can see, only the last instance of MyView is actively referenced somewhere. That means that the first 4 instances are ready to be collected during the next garbage collection.

One thing i don’t understand though, is that the reference chain of the last instance doesn’t mention MainPage or the event handler anymore. But when i attached Visual Studio’s debugger to the browser instance i could clearly see that the MyEvent of MainPage indeed contained an event handler that pointed to this MyView instance. I’m far from a WinDbg and SOS expert so i have no idea why the reference chain doesn’t reflect this. Perhaps someone with more WinDbg and SOS knowledge can shed some light on this?

Either way, this approach is a pretty good way of finding memory leaks in your Silverlight code. In a real application it’s obviously a bit more complicated to find the exact cause of a leak compared to this simple example, but it’s still pretty doable. Just execute the !dumpheap -stat -type YourRootNameSpaceHere and look for unusually high numbers of instances of your types. Then you can start looking at each instance to figure out what’s going on. And for a nice list of commands that you can execute in WinDbg with SOS, be sure to check this out.

Also, keep in mind that you can do this for every .NET process, and not just Silverlight. Though you would need to load the sos.dll file of your particular .NET version.

In the past i have resorted to grabbing a memory dump of the browser and analyzing the content of the managed heap with windbg to track down which instances where being kept in memory. While this works, it’s pretty time consuming and can quite easily lead you down the wrong path. One of the most important things that you want to know in this specific case is: which types are being kept in memory, and how many of them?

In this case, being able to query something during debugging regarding which instances are still kept alive in memory at certain times is sufficient for me. So i came up with the following class:

The idea is basically to just keep a list of WeakReferences of objects you want to track (only if a debugger is attached), and later on you can ‘query’ the live instances through the GetAllLiveTrackedObjects method. This method obviously performs a full garbage collect to make sure only objects that are really still alive are returned. Again, you should almost never do a GC.Collect() manually, but in this case the method will only be called while you’re debugging.

Then, you strategically put the following line in the constructor of every kind of type you’d like to track:

I have that line in the constructor of my base View class, my base Controller class and in my base Disposable class. So now, when i want to check if there are any dangling references to instances of types that i really don’t want hanging around, i can just do something like this:

And then manually inspect the content of the liveObjects collection. It’s far from perfect, but at least it’s an easy way to at least know which instances (that i care about) are being kept in memory. It’ll do until we get better tool support :p

We basically had a custom UserControl which contained (among other things) a Repeater which would render another custom UserControl. Nothing really weird there, right? The problem was that the custom UserControl that was created by the Repeater explicitly needed to be disposed. No problem, System.Web.UI.Control implements IDisposable so we could just override the Dispose method, perform our cleanup there and then proceed with the base Dispose implementation.

Now, i’m far from an ASP.NET expert but i was under the impression that all Page and UserControl instances would always have their Dispose method called if they were created by other ASP.NET controls (containing pages or controls). After all, what’s the point in implementing IDisposable in the base Control class if you’re not even going to guarantee proper usage of the pattern, right?

Well, as Kristof describes in his post, there is at least one situation where a UserControl is not disposed of, even though it was created by a Repeater. In our case, the leak was subtle. It took a stress test of 10 hours with a load that would be comparable to real world usage of one month to expose the leak. A lot of people would say “oh, let’s just recycle the application pool periodically and everything is A-OK”. But the very idea of having to recycle an application pool periodically to keep a system up and running is just a cop out to me. Good code should not require periodic restarts. Period.

I wonder how many ASP.NET WebForms applications might actually have the same (or at least similar) problem(s) like the one Kristof encountered. If everyone keeps recycling their application pools periodically, we unfortunately may never found out.

So i started looking into the usual things: making sure disposable instances where disposed of properly, that evenhandlers were unregistered properly, etc. I went over the code and it seemed to be alright. Stepping through the code with a debugger verified that disposables were indeed disposed of, and that all event handlers were unregistered.

So why was pretty much everything kept in memory? Further research with windbg showed that every ProgressBar instance that was ever created (and we use a lot of them, basically every time we make a call to the application server) kept a reference to the UserControl it was placed on and thus, kept the UserControl and all the references it contained alive. In our case, that includes our presentation models and obviously all of the contained child UserControls.

The ProgressBar is defined like this:

The key here is the usage of the IsIndeterminate property… setting this to true causes the ProgressBar to move continuously without respecting any current Value property. You know, basic stuff. The thing is… if i change the definition of the ProgressBar to this:

The memory leak suddenly went away

Obviously, this isn’t a solution because the ProgressBar now doesn’t really indicate any progress and we need our kick ass custom animation to retain the coolness of the application.

So for some reason, when you set the ProgressBar’s IsIndeterminate property to true, it actually keeps all of its references alive even when the ProgressBar control is removed from its parent control. Happy times.

We now have the following ugly method in one of our base UI classes:

• Using GC Efficiently, Part 1
• Using GC Efficiently, Part 2
• Using GC Efficiently, Part 3
• Using GC Efficiently, Part 4

If you’re using an IOC container it’s important to not use it all over the place. You basically use it in as few places as possible to resolve a component and you let the container sort out all of the dependencies. So in the few places where you use the container directly, you need to resolve the component, and in case of transient components you also need to release them through the container. Releasing it is very easy to forget, so i wanted something that would guarantee that the component would be properly released. Enter the Resolvable class:

The Resolvable class inherits from my Disposable class, so the Disposable pattern is correctly implemented.

From now on, instead of calling the container directly, i just instantiate a new Resolvable in a using block. Let’s try it out.

I’m reusing my test component with a dependency from one of the previous posts:

Now, instead of resolving an IController directly through the container and having to dispose of it, i just do this:

The container doesn’t hold the reference to the instance, and both the instance and its dependency is properly disposed.

This prompted the following comment by Bryan Watts:

So Controller is responsible for disposing of something it did not explicitly create? That’s a little presumptuous isn’t it?

> if you own a reference to an IDisposable instance, you are responsible for properly disposing of that instance.

I agree (and I’ve read your other article). However, in this case, Controller clearly does not own its dependency.

And Bryan is right. For a lot of languages, memory management rules can be summarized (somewhat simplified) like this:

• If you create an instance of a class, you are responsible for releasing/freeing/disposing it.
• If a factory creates an instance of a class, the factory is not responsible for releasing/freeing/disposing it. This burden falls upon the object which requested the object from the factory
• If you receive an instance of an object, you should not release/free/dispose it, unless you received the instance from a factory

So where does this leave us with the example code shown above? Clearly, we did not create the instance of the disposable dependency, so in theory, we are not allowed to dispose it. Then again, if we weren’t using Dependency Injection we would have probably instantiated the disposable dependency in our constructor (or when we first need it). In that case, we would have been responsible for disposing the disposable dependency.

You could argue that the IoC container is in some way a factory which creates and supplies the dependency to our class. So according to the rules stated above, it would be allowed to dispose the dependency. The downside to this is that this means that our class (the Controller) has knowledge of the lifecycle of the dependency. We know that the dependency has been configured with a Transient lifecycle (which means the container creates a new instance whenever an instance of its class is needed) so we can safely dispose it. The problem is that this knowledge is implicit. It is nowhere visible in the code of the Controller class. The only place where this lifecycle is configured explicitly, is in the configuration of the IoC container so it would be wrong for the Controller to assume anything about the lifecycle of its dependencies.

After all, suppose someone makes a change to the code of the dependency which makes it possible to be used with a different lifecycle. Suppose someone makes the change to the dependency and then configures the IoC container to always return a singleton instance of this dependency. If nobody thinks about the fact that the Controller still assumes a Transient lifecycle of the dependency, the disposal of the dependency will not be removed from the Controller class. Once a Controller instance is created, and then disposed, it will try to dispose the instance of its dependency, which will cause problems because that instance is supposed to be used by other objects as well!

So what do we do? Do we dispose of the dependency in the Controller class because we know it’s safe (until someone changes the dependency and/or its configuration with the container)? Or do we simply not dispose it (since we’re not really allowed to do so without some kind of implicit knowledge of the ‘outside world’)?

Neither option sounds very appealing. The first option could lead to problems depending on possible future changes outside of the Controller class. The second option is already problematic because a disposable dependency is not being disposed of as fast as it should be. The disposal would basically be postponed until the instance is collected by the garbage collector.

Another alternative is to have the container inject a factory which can create transient instances of the dependency, instead of having the container inject the transient instance directly. This would fix all of the discussed problems: the controller would not need to dispose the injected dependency, and can safely dispose the instantiated disposable instances. However, having to create factories simply to avoid this problem seems a bit cumbersome. The implementation of the factory could lead to other discussions as well because of how the factory should create the actual instance and its dependencies, which is exactly the reason why we wanted to use an IoC container in the first place. True, the factory could resolve the instance directly through the IoC container, but then you’re just moving the problem to a different class without actually fixing it properly.

This entire problem has been described as the Component Burden by Hammet, the original creator of the Windsor IoC container. Obviously, this is something that the container should solve for us instead of us having to worry about it. Ideally, the container would keep track of all of the disposable dependencies it has created to satisfy the creation of requested components. Then when the requested component would be released, the container could safely dispose of each transient disposable dependency it created to create the requested component. Luckily, the Castle developers have implemented this behavior recently, so if you’re using a recent build of the Windsor IoC container, this problem should no longer occur and you shouldn’t be forced to dispose of dependencies that were injected into your objects.

The reason why i’m not using it yet is because there were many attempts at implementing this, and most attempts had considerable downsides to them. This one has been committed to the trunk, so it’s probably a good solution, but i’m not going to use this solution in production systems until it has had some more time to prove itself. So for now, i’m sticking with my approach where i manually dispose the injected dependencies. I know it’s not the best approach, but until the real solution in the container is somewhat more proven to work without downsides, manually disposing the dependencies seems to be the lesser of multiple evils.

Keep in mind that i’m only talking about the Windsor IoC container. I have no experience with StructureMap, NInject or Unity, so i have no idea how these containers deal with this problems. If anyone with knowledge about these container could shed some light on how they deal with this, i’d be very interested in reading it

My mistake was that after i was done with the components that i asked Windsor to resolve, i simply disposed them (which in turn would dispose their dependencies) and i figured that would be enough, since my components are registered as Transient. That means that each time you request a Transient component, you get a new instance. This led me to believe that Windsor wouldn’t need to hold a reference to the constructed components so i figured that simply disposing them would be enough, since they are IDisposables. Disposing them is a good thing obviously, but because the container was still holding references to the requested components, that’s still a lot of memory that is being wasted because even though you’ve disposed them, they aren’t eligible for Garbage Collection until they are no longer accessible. And because the container kept references to them, they remained accessible and were never collected. And there was my memory leak. Oops.

In order to prevent this problem in the future for myself and anyone else who reads this, let’s go over a few examples which should make it clear how you should make sure that your components are properly released so they are eligible for garbage collection.

Let’s start really simple. We have an IController interface and a simple Controller class which implements the IController interface:

In our tests, we’ll use the following method to create and configure the container:

The IController interface is registered with the container, and the container will return a new Controller instance (because of the Transient lifestyle) whenever someone requests an IController instance.

The following test highlights the memory leak that i was experiencing:

When you request a component from the Container, it keeps a reference to that instance in its Kernel’s ReleasePolicy object. If you merely dispose of your requested component, the ReleasePolicy still holds the reference to the component. This is what caused my memory leak.

So how do we avoid this problem? It’s pretty easy actually:

Instead of just disposing our controller, we tell the container to release it. The container in turn knows that because IController inherits from IDisposable, it should dispose the Controller instance. It also removes the instance from its Kernel’s ReleasePolicy object and once your own reference to the Controller instance goes out of scope, it’s eligible to be collected by the Garbage Collector.

As you can see, it’s very easy to make sure your components are properly released and eligible for garbage collection. But what about possible dependencies of your components? Let’s take a look.

Suppose we define the following interface and implementation:

The dependency doesn’t actually do anything, but bear with me

We modify the IController interface and Controller implementation like this:

And then we modify the configuration of the container like this:

Whenever we request an IController instance, the container will construct a Controller instance and will pass a MyDependency instance to the Controller’s instance constructor. The question now is: does the container also track the instances of a requested component’s dependencies? The answer is: no

We request an IController instance, which is tracked by the container. The IController’s Dependency property contains an IDependency instance, which was also created by the container. But as the last line of the test shows: the container does not track instances of the requested IController’s dependencies.

So what does that mean? If the dependencies don’t require any cleanup, then this is great. We simply need to release the requested component, and the component and its dependencies will all be eligible for Garbage Collection.

(Note 27/01/10: the following part is no longer relevant as of Castle Windsor 2.1)

But what happens when the dependencies need to be disposed? Let’s take another look.

We modify the IDependency interface and MyDependency class so it looks like this:

Now let’s see what happens with the Controller’s dependencies when we release the Controller:

The container holds no references, but the Controller’s Dependency instance is not disposed! Notice however that the Controller has been disposed by the container. As i’ve mentioned earlier, if you own a reference to an IDisposable instance, you are responsible for properly disposing of that instance. So we modify the Controller’s Dispose method so that it looks like this:

The previous test will now fail, because the Dependency will be properly disposed.

NOTE: i certainly don’t recommend to implement your Dispose methods like i just did. This is just a simplified example. The proper way to implement the Disposable Pattern is discussed here.

Anyways, i hope it’s clear now how you can make sure your IoC usage does not cause memory leaks, and that everything is properly disposed of.

A recent internal email thread unearthed extreme differences of opinion about when Dispose(void) should be called on an IDisposable. The rival suggestions were:

1. Always call Dispose

2. Avoid calling Dispose; rely on cleanup at finalization

This led to a long discussion and a realization that — while it seems like we’ve said everything there is to say about Dispose — it’s time for some more Dispose guidance.

I don’t know about you guys, but the thought of Base Class Library developers not being sure on when Dispose should be called is something that makes me quite uncomfortable. If anyone should know, it’s these guys, right?

Another interesting quote from the post:

Whatever distinction we eventually use, API docs should explicitly call out IDisposables that must be Disposed.

Great… now we are supposed to rely on the MSDN docs to find out which IDisposables need to be disposed and which ones don’t.

I kinda like the IDisposable pattern, but it’s truly a shame that there are so many types that implement the IDisposable interface without really needing to implement it. I’ve always considered the IDisposable interface to be a contract which states “if you use me, you must dispose me”. For certain types, this is true. Unfortunately, for other types that implement the interface it’s not true even though the IDisposable documentation is pretty clear about this:

When calling a class that implements the IDisposable interface, use the try/finally pattern to make sure that unmanaged resources are disposed of even if an exception interrupts your application.

In a perfect .NET world, there would be no types implementing IDisposable without actually requiring disposal (IMHO). Again, i think the interface is a contract that must be followed by everyone who makes use of it. Then again, it does feel pretty pointless to dispose types of which you know that it really doesn’t make a difference.

The introduction of explicit Code Contracts in .NET 4.0, got me thinking about trying to make disposal of types that really require it enforced by the compiler. What i have in mind is not possible with the Code Contracts in .NET 4.0, but it’s something that i think would be a good addition to the .NET Framework.

Suppose we could do the following:

Basically just a type which implements IDisposable, and there’s an attribute that specifies that the disposal of this type is really required. The following code should then fail to compile:

Whereas this code would compile without errors:

It’s just a thought and obviously, this isn’t possible right now. But i think it would be great if it were possible. We could do all sorts of things with this approach… for instance, if an object owns a reference to an IDisposable type which has the [RequiresDisposal] attribute, the compiler could enforce that the object owning the reference must implement IDisposable and have the [RequiresDisposal] attribute as well. I think we’d end up with a system were types that really require disposal can’t be used without properly disposing them.

Thoughts?

We were clueless as to why the calls were actually blocking. We had a few scenarios that would usually (but not always) trigger the bug, but it also occurred in other situations, seemingly at random. So my coworker spent many hours trying to find out why it was happening. After a lot of debugging on his part, he found out that sometimes our WCF proxies weren’t being disposed, which left Channels to the service open which caused new proxies to block whenever the number of allowed concurrent channels was reached. My first reaction was “huh, how could that be? i’m disposing of them in the page’s PreRender event…”.

First of all, i’m far from an ASP.NET guru, so those of you who do know a lot about it probably already understand the problem. I figured that the PreRender event would always occur, and that it would be the best place to dispose the WCF proxy. That turned out to be a two-for-one brain fart on my part. First of all, the PreRender event is obviously not fired when you do a Server.Redirect or Server.Transfer, so whenever we navigated to another page, we did not dispose our WCF proxy. Secondly, Page inherits IDisposable, which i completely missed apparently. So, had i simply overridden the Dispose method and dispose the proxy in there before calling base.Dispose() and then we would’ve never had this problem to begin with.

Lesson of the day: no matter how careful you try to be, you can still fuck up pretty bad sometimes

Update: i actually used the PreRenderComplete event instead of the PreRender event… still, a bad place to dispose of disposable objects

Suppose we have the following Publisher class:

And then we have a BadSubscriber class:

Notice how the BadSubscriber subscribes to the Publisher’s event, but never unsubscribes from it.

Then we have the GoodSubscriber:

The GoodSubscriber is very similar to the BadSubscriber, but it unsubscribes from the Publisher’s event when it is disposed. Note that the implementation of the IDisposable interface is hardly ideal, but for the purpose of this demo it’s sufficient.

The following code illustrates the problem:

The output of that code is the following:

the publisher notified the bad subscriber of an event
the publisher notified the good subscriber of an event
good publisher is gone
bad publisher is alive
the publisher notified the bad subscriber of an event

Notice how the GoodSubscriber is removed from memory by the GC and how the BadSubscriber is still in memory even though we no longer have a reference to it and the GC has performed a collection.

So keep in mind that every event handler you subscribe to an event should be properly unsubscribed from the event when your instance is no longer needed. Not doing so might lead to instances not being removed if the event’s publisher has a longer lifetime than your object will have. I’d actually suggest you’d always properly unsubscribe from any event you subscribe to. Even if you know that the Publisher won’t have a longer lifetime than your instance will have, who’s to say some future change in the code won’t extend the lifetime of the Publisher over that of the Subscriber? When that happens, you might end up with a bunch of instances that will remain in memory as long as the Publisher remains in memory.

Garbage Collection sure is great, isn’t it? We don’t have to keep track of all the memory we’ve allocated and we don’t need to release that memory when it’s no longer needed. Because that is after all what the Garbage Collector does for us, without us having to worry about it. This is actually a widespread misconception among many .NET developers. It’s true that Garbage Collection makes memory management a lot easier, but we simply can’t rely on it all the time. There are most certainly some things you must always keep in mind when it comes to memory management in .NET.

Different Kinds Of Resources, Different Consequences

In most pieces of code, you use variables. A lot of these variables are references to objects. When your variables go out of scope, they no longer exist. When those variables are references to objects, only your reference is gone and the actual object that was referred to is still in memory somewhere. The Garbage Collector (GC) makes sure that orphaned objects (objects that no longer have a usable reference to them) are removed from memory. This is an automatic process within the .NET runtime. Essentially, the GC periodically performs some checks on objects and if it comes to the conclusion that certain objects are no longer needed, it will remove them from memory. This is a gross oversimplification of how it really works, but that is what it comes down to and that is also how most people think about the GC.

The GC in .NET is very smart and will almost always do a better job of memory management than you will. But there is one huge downside to it: the GC runs periodically and you have no deterministic way of knowing when it will run. Sure, you can instruct the GC to perform a collection but in most cases that will actually have a negative impact on the memory management of your application. I won’t go into the details here, but i will provide a follow-up post on this later on. For now, keep in mind that forcing a garbage collection to occur is really something you should avoid.

So is it really a problem that you don’t know for certain when the GC will run? It depends on which kind of objects that need to be removed from memory. There are basically 2 kinds: managed and unmanaged resources. Managed resources are typical .NET types. Unmanaged resources (also referred to as Native Resources) are things that fall outside of the scope of the .NET managed environment. These are usually things that are available within the Operating System, or that are available through lower-level development API’s (such as the Win32 API for instance). Unmanaged resources can’t be cleaned up automatically by the .NET runtime, so if you use them directly, you are responsible for cleaning up after you’ve used them. Luckily, a lot of managed types are available that take care of the dirty details for you. For instance, if you need to use a file in .NET, you’ll typically use a FileStream instance or something else that easily makes the content of the file available to you, or that easily allows you to write content to a file. The FileStream is a managed type, but it uses unmanaged resources to implement the functionality it offers.

Now think about this: you are using a managed type, so you shouldn’t need to perform any cleanup, right? However, if that managed type uses unmanaged resources then they still need to be cleaned up. And those unmanaged resources should be cleaned up as soon as possible because they can be quite expensive. These types usually offer a way to clean up the unmanaged resources they use in a deterministic manner. They usually implement the IDisposable interface, which exposes a Dispose method. When you call the Dispose method, the unmanaged resources are cleaned up right then and there and then there’s no need to wait for the garbage collector, which again, could be quite expensive when you (either directly or indirectly) have a bunch of unmanaged resources in memory that are waiting to be cleaned up.

Disposable Managed Resources

I call types that implement the IDisposable interface Disposable Managed Resources. They are indeed managed types and thus they are guaranteed to be cleaned up when the GC comes around and notices that instances of these types are no longer needed. However, if you merely trust on the GC to clean up instances of these types you are taking quite a risk. Any expensive resource it may hold might be cleaned up a lot later than it could have been. Which can be very inefficient, and thus, quite costly.

If a type implements the IDisposable interface, it usually has a good reason for doing so (there are of course exceptions to the rule). It is essentially a way of telling consumers of the type that it offers a deterministic way of cleaning up the resources it consumes and i believe you should take advantage of that. If you don’t, you may end up with inefficient memory management, and that’s when people start complaining that Garbage Collection is ‘evil’ or that it ‘sucks’. In most cases, people who feel that way simply don’t know how to use it properly. The IDisposable interface and the Dispose Pattern (which we’ll get to in a minute) allow you to avoid most of the issues that are generally attributed to the Garbage Collection in general.

So how do we deal with this? First of all, if a type uses unmanaged resources, it should implement the IDisposable interface using the Dispose Pattern. Secondly, if any of your types use other types that implement IDisposable, it is your responsibility to make sure these types are properly disposed of. You either dispose them when you no longer need them, or you must implement IDisposable and the Dispose Pattern yourself to make sure the Disposable Managed Resources you depend on are indeed properly disposed of. If you need to implement IDisposable, your type effectively becomes a Disposable Managed Resource itself. A lot of people think that this isn’t necessary, but by not doing so they are breaking the contract that the IDisposable interface implies. If a type implements IDisposable then either that type or any other type it may use probably uses unmanaged resources somewhere and you want to see these get cleaned up as soon as possible. Because of that, i believe it’s best to implement IDisposable yourself if you’re holding any reference to a type that also implements it.

The Dispose Pattern

Implementing the IDisposable interface can be as easy as merely providing a public Dispose method where you perform your cleanup. That’s really not a good way of doing it though, as it could lead to a bunch of other problems which might actually make the situation worse. The best way to implement the IDisposable interface is to implement the Dispose Pattern, which looks like this:

If you don’t need a finalizer it’s best not to provide one (we’ll discuss finalizers later on). If you do need one, you would implement it like this:

So what’s so good about the Dispose pattern? Well, we make a clear distinction between what should happen when the object is disposed through the Dispose method, or when it’s being cleaned up by the finalizer. When the clean up occurs through a call to Dispose, it calls the protected virtual Dispose method with the disposing parameter set to true. When this parameter is true, you should call the Dispose method of each Disposable Managed Resource you’re holding a reference to. Outside of the if-statement, you should clean up each unmanaged resource you may be holding.

If your class (or a derived class) implements a finalizer method, it should call the Dispose method with the disposing parameter set to false. The reason for this is that the order in which objects are finalized is not specified. If you’re not careful, you could accidentally call the Dispose method of a Disposable Managed Resource which may have already been finalized as well. This would cause an exception and a finalizer method should never ever throw an exception because that could keep other objects from being finalized.

If you can, try to put this pattern into a reusable base class and make your Disposable Managed Resource holding types inherit from this. An example of this approach can be found here.

Using Disposable Managed Resources

In a lot of cases, you will use a Disposable Managed Resource within the scope of one method. In that case, you certainly don’t need to implement IDisposable. There are two things to keep in mind though. If you receive the Disposable Managed Resource as a method parameter, you are not responsible for disposing it! Somebody else created it, let them take care of the disposal. Things will most likely go wrong if you dispose objects that have been giving to you by somebody else. So in this case, you would just use the object and not worry about it any further:

However, if you create the object yourself, then you are responsible for getting rid of it properly. In that case, use a using block to make sure the object is disposed of even in case of unhandled exceptions:

In case you don’t know, the using-block guarantees that the Dispose method will be called when we leave the scope of the block. It can get pretty tricky sometimes if you’re passing the Disposable Managed Resources to other objects that will hold a reference to them which will remain in use after you’ve left the using block. In this scenario, it’s possible that the object you’ve passed the Disposable Managed Resource to will try to invoke methods on the disposed instance. Also a situation you most certainly want to avoid because it will either cause unexpected behavior or even unhandled exceptions. The unhandled exceptions are easy to figure out, but the unexpected behavior might be difficult to debug. The key in this scenario, is to figure out a way to not call Dispose on the resource until the other object is done with it. Sometimes it might be enough to put your using block on a slightly higher level, other times you’ll have to keep a reference to the resource yourself, which effectively means you’ve now become an owner of the Disposable Managed Resource.

Owning Disposable Managed Resources

If you need to hold a reference to a Disposable Managed Resource, you are either the owner of the object or at least someone who owns a stake in the lifetime of the object. If you are the owner, and you do not pass the Disposable Managed Resource to any other object then the solution is easy: implement IDisposable. If you do pass the Disposable Managed Resource to other objects, then it can get tricky. Will they only use it to perform some action or will they hold a reference to it? If they hold a reference to it, it means that they too have a stake in the lifetime of the resource. Depending on the implementation of the other types, they may or may not call the Dispose method of the instance you created. Which could cause unexpected behavior or exceptions in your code. Make sure you are prepared for that if you’re passing these objects around. But you should definitely dispose of them in your own Dispose method.

If you didn’t create the Disposable Managed Resource, but you do need to hold a reference to it, then you’ve got some questions to answer. Does the type which provided you with the instance expect you to be solely responsible for the lifetime of the object? In case of factory classes or factory methods, the answer is usually ‘yes’. If you’ve been given the instance by something that will probably make use of that same instance, i think it’s better not to dispose it. Some people will probably disagree, but i don’t think it’s my responsibility to dispose objects that i didn’t create, unless the instance was given to me by a factory class or a factory method. I would expect that the real owner of the resource would dispose of it. Still, it’s a difficult call to make.

Finalizers

Finally, i’d like to add a few words about Finalizers in .NET. A finalizer is similar to a destructor in C++, in that it is the code that is run when your object is being removed from memory. The big difference is that you never know for sure when it will be run, which is why the IDisposable interface and the Dispose pattern was created. There are a lot of misconceptions going around about finalizers, so keep the following comments in mind.

First of all, finalizers only make sense when you have direct references to unmanaged resources. If you have unmanaged resources, implement IDisposable and provide a finalizer that calls the Dispose overload with the disposing parameter set to false. This should really be the only code inside your finalizer method.

Finalizers also come with a performance penalty. When finalizable objects are created, pointers to these objects are added to the finalization queue of the GC. These finalizable objects are collected less frequently because the GC performs finalizations through its finalization queue. This finalization process is not executed as frequently as regular garbage collections because it’s quite costly. So not only are finalizable objects cleaned up less frequently, it takes more processing power to do so. So if you have a lot of finalizable instances, your code’s performance can easily be impacted because of this.

Conclusion

I hope i made it clear that there is a lot more to automatic memory management in .NET than simply relying on the GC to take care of all of the details for you. There is a lot more stuff that i didn’t cover in this post (it’s long enough already) but most .NET developers will probably get by pretty well with the advice given in this post. It’s not an easy subject to explain so i hope everything was clear

So now i can simply inherit from Disposable, and i just need to implement the two abstract methods. Here’s a made up example to illustrate this:

Obviously, you can’t use the Disposable base class if you’re already inheriting from another base class so in that case you’d still have to implement the IDisposable interface.

Update: Here‘s a thread-safe version of this idea.