Nulling Out Managed Resources on Dispose

Question

Possible Duplicate:
Any sense to set obj = null(Nothing) in Dispose()?

I understand if this question is closed as a duplicate, but I'm having some trouble reconciling some posts on this topic.

First a little background. I have a class Foo as follows

public class Foo : IDisposable
{
    private Dictionary<int, string> _reallyBigDictionary = 
            new Dictionary<int, string>();

    public void Dispose()
    {
        _reallyBigDictionary = null;
    }
}

Instances of Foo are known to have a limited scope (i.e. I know we're not keeping it around forever). Given it's instance's limited scope, I don't see how nulling out _reallyBigDictionary actually frees up memory sooner than the dispose. The way I understand it, these objects won't ever get cleaned up until garbage collection is run. At that time, references to the given instance of Foo will be null regardless, so I expect GC to reclaim that memory regardless.

These posts lead me to believe that there is no point in setting member variables to null:

Memory leak problems: dispose or not to dispose managed resources?

Is it better to destroy all objects or just let the garbage collector do the job?

This post makes me question otherwise: Proper use of the IDisposable interface

Can anyone clarify this point for me? Is the IDisposable implementation really necessary here? Because I just can't convince myself it is.

Answer 1

You don't need IDisposable; here's why. In summary, you need to follow Rule 1: Don't implement IDisposable unless you need to.

There are only two situations when IDisposable does need to be implemented:

• The class owns unmanaged resources.
• The class owns managed (IDisposable) resources.

Since Dictionary<int, string> is not IDisposable, your class shouldn't be either.

Answer 2

By implementing the IDisposable interface you can scope the useage of resources with the Using statement. Also many classes in the underying .NET Framework detect that a class is IDisposable and runs the Dispose() for you, absolving you of the responsibility of nulling your managed child objects.

EDIT ----

Because of comments and a markdown, I thought Id add to my answer :

Many many classes in the .NET Framework implement IDisposable - for example many Generic collection types. When you dispose of such a collection the Microsoft implementation will call your class's Dispose method, having detected that it implements IDisposable. Also, there is a case for setting a reference to an object to null genrally - including perhaps in your Dispose method. If you want to remove a reference to an object, set the reference to null. Other classes might want to maintain a reference to the same object, so the argument that setting a reference to null is wrong' is a flawed argument. Using your Dispose method to set the reference to null is no different than setting it to null in any other way - granted, but by doing it in your IDisposable implemnentation you can have a far more determinitic and error-proof way of ensuring that this happens. Implementing IDisposable is also an excellent way to implement scoping, e.g. for transactional algorithms etc. Implementaing IDisposable is usefull in many ways and neednt be avoided, as long as you know how and why it works. It always amazes me how few .NET developers truly understand the IDisposable interface, Finalizers, the garbage collector and .NET best practices in general

Answer 3

I don't think that disposal is necessary in this instance. It's not like it's an active connection that's going to stay open and keep using up resources. When you're done using it, it will manage itself.

If you really want to make sure that there are no memory leaks coming from that piece of code, you can try adding the following to the dispose method:

GC.Collect();