When should I dispose my objects in .NET?

Question

For general code, do I really need to dispose an object? Can I just ignore it for the most part or is it a good idea to always dispose an object when your 100% sure you don't need it anymroe?

Answer 1

If the object implements IDisposable, you should dispose of it as soon as you are done with it. The easiest way is to surround it with a using block:

using (SqlCommand cmd = new SqlCommand(conn)) {
    cmd.ExecuteNonQuery();
}

Answer 2

Relying on the GC 'works' in most instances. The classic exception is when you have a resource heavy interaction - in that instance it is best to explicilty dispose.

obvious eg.

using (var conn = new SqlConnection(connString)) {}

'Using' blocks are definitely the cleanest and most robust method of ensuring that objects are disposed of correctly. 'Using' blocks can be leveraged with any objects that implements IDisposable.

Answer 3

When you're done with an object you can forget about it. As long as it's not referenced anywhere then it's as good as gone. The memory it uses is freed up when the garbage collector feels like it.

Answer 4

There are a couple of ways to look at it. One way tries to figure out if it's really necessary to dispose of an object as soon as it's no longer needed, for example using Reflector to see if it really is holding onto unmanaged resources, or if they were incidentally disposed of anyway. The other perspective is to assume that if an object implements IDisposable, it's not your business to determine if Dispose() really needs to be called--you always call it. I think that is the right way to go. Peeking into the private implementation of objects to make decisions about how you should consume them increases your risk of getting coupled to an implementation that could change. An example is the LINQ to SQL DataContext. It implements IDispose but mostly cleans up after itself without the need for an explicit call to Dispose(). My preference is to write code that explicitly disposes anyway, but others have suggested its not necessary.

Of course this all applies to objects that implement IDisposable. It's true that the GC will take care of most everything else without any explicit action on your part, but it's worth reading up a bit on the subtleties of GC behavior (I'm too tired to think of the details right now) to know when to dispose of objects explicitly, and more importantly, when to implement IDispose. There are lots of good articles on the interwebs on the matter.

And as said previously, using(..) { ... } is your friend for IDisposable implementors.

Answer 5

The reason you should always call Dispose() on any type that implements IDisposable, is that it is usually used to signify that the type acquires unmanaged resources. It is especially important that these are freed, and as early as possible. As others have mentioned, using is the prefered way to do this.

Answer 6

Dispose of an object the instant your are done with it. Disposable objects represent objects holding a valuable resource which the CLR is not intrinsically aware of. Consequently the GC is also unaware of the resources and is unable to make intelligent decisions as to when it should collect a disposable object and hence free the underlying resource.

Eventually the GC will feel memory pressure and collect your object by coincidence (nothing more). If you don't dispose of objects in a deterministic manner then it is completely possible to enter a resource starved state with almost no memory pressure.

Quick example of how this can happen. Lets think of the underlying resource as Win32 handle. These are very finite and fairly small. You run an operation that create a lot of Foo objects. Foo objects implement IDisposable and are responsible for creating and disposing of a Win32 handle. They are not manually freed and by a difference quirk make it into the Gen2 heap. This heap is freed fairly infrequently. Over time enough Foo instances make it into the Gen2 heap to take up all of the available handles. New Foo objects are consequently unable to be created regardless of how much memory is being used.

In fact to free the handles, it would take a rather large amount of memory to be allocated during a single operation to give enough pressure to free the instances.

Answer 7

If the object implemented IDisposable, it is quite likely that it is holding on to unmanaged resources. The rule of thumb, therefore, would be to call Dispose the moment you are done with the object, either directly or via a using block. Don't rely on the GC, since that's what the IDisposable is for - deterministic release of resources.

Answer 8

No you can get away with calling Dispose in the cases where you are not holding an unmanaged resource. But if your class is holding an unmanaged resource say, a temp file that needs to be deleted, then you will have to explicitly call Dispose.

You can avoid calling Dispose by writing your freeing code in Finalize method but then you are dependent on the Garbage Collector because you are never sure than when Garbage collector will finalize your object. To be on the safe side, if you are designing such a class which holds an unmanaged resource, you can write the same object-freeing code in both Dispose And Finalize method but if you do so, always use SuppressFinalize() in your dispose method because it will prevent the Finalize() method from being called if your object is already on the Finalization Queue.

Answer 9

i think person asked when? means he is quite sure abt the performance degrade & wants to dispose manually.