Why call Dispose()? Memory leak won't occur?

Question

Edit: My question isn't getting the main answer that I was looking for. I wasn't clear. I would really like to know two things:

1. Can NOT calling Dispose() cause memory leaks?
2. What's the worst thing that can happen if you have a large program and never call Dispose() on any of your IDisposable objects?

I was under the impression that memory leaks could occur if Dispose() isn't called on IDisposable objects.

Per the discussion on this thread, my perception was incorrect; a memory leak will NOT occur if Dispose() isn't called.

Why ever bother calling Dispose() then? Is it just to free the resource immediately, instead of sometime later? What's the worst thing that can happen if you have a large program and never call Dispose() on any of your IDisposable objects?

Answer 1

Dispose is used to release non-managed resources. This could mean memory, if a class allocated non-managed memory, but it is more often native objects and resources like open files and database connections.

You often need to call Dispose on a class that itself doesn't have any non-managed resources, but it does contain another class that is disposable and may have non-managed resources.

It's also sometimes useful for developers to implement dispose to ensure deterministic finalization--guaranteeing the order in which resources are freed.

Also note that classes that implement dispose often also have a finalizer to release resourcdes if Dispose is not called. Objects with a finalizer have a different life-cycle than classes without one. When they are ready for GC, the GC will see that they have a finalizer and instead of immediately collecting the object when the GC is ready to, it puts it into the finalization queue. This means that the object lives for one extra GC iteration. When you call dispose, the implementation usually (but is not required to) calls GC.SuppressFinalize() which means the finalizer no longer needs to be called.

If a class implements IDisposable, you should always call Dispose().

Answer 2

Not calling Dispose will not ever (*see note 2 on wrong implementation) cause traditional "memory leak" (memory is never freed till end of the process).

The "only" thing that will happen in relation to memory is it will be freed in non-deterministic moment in the future.

One interesting case of non Dispose objects is when very small managed objects hold large amounts of unmanaged memory (i.e. allocated with some flavor of Win32 memory management functions i.e. HeapAlloc ). In this case managed memory manager may not be able to detect memory pressure properly to trigger Gen2 GC and (especially in case of x86 - 32bit process) it may prematurely fail to allocate managed memory for your process. The other issue in this case is fragmentation of address space by "waiting for GC to be de-allocated" (again mostly in x86 case) - when smaller chunks of native memory are allocated with some relatively large space between them preventing allocation of large blocks needed for managed memory management.

Notes:

1. This answer explicitly talks about true memory leaks/memory allocation issues cased by not disposing IDisposable object managing memory. While it is true that there are no "true memory leaks" caused by such practice most people will consider growing memory usage as memory leak (similar to storing large amount of objects in static list/dictionary for lifetime of an application).
2. One can create object that manages native memory and incorrectly implements IDisposable pattern. In this case it is possible to really leak native memory (irrespective of calling Dispose).
3. In most cases objects that implement IDisposable don't managed memory at all. For most practical C# programs native resources managed by such objects are handles for system resources like files, bitmaps, fonts, synchronization objects or COM native objects. Not disposing them in timely manner will cause other issues.

Dispose all objects properly. There is no excuse not to.