Disposing has nothing to do with garbage collection, unless the developer uses disposing for some purpose related to GC. If you mean
System.IDispose and its implementation in different types, it is nothing but an abstract interface which can be used for anything at all. One of the uses is disposing of unmanaged resources which cannot be affected by GC, but this is just one of the purposes. Also, you should not forget some methods which are called
Dispose but are unrelated to
System.IDisposable. One of the technique of using
System.IDisposable is the
using statement (not to be mixed up with
using directive):
http://msdn.microsoft.com/en-us/library/yh598w02.aspx[
^].
Generally,
Dispose is something which is controlled by the application code, no matter what it does. Garbage collection and related destructor and
Finalize methods work in a very different way: its behavior is not directly controlled by the application. Instead, GC tracks the
unreachable objects and eventually reclaims the memory, destructing the objects before it, which calls the constructor. The concept of
reachability is not as simple as it may seem: if, say, 3 objects reference each other in cycle, they are still detected as unreachable if there are no other references. Please see:
http://en.wikipedia.org/wiki/Garbage_collection_%28computer_science%29[
^].
In other words, there are no such operations on your application API which "free" managed memory. The moment of time when the managed memory is reclaimed is chosen by the GC and is unpredictable from the application perspective. By these two reasons, destructors are rarely needed in a .NET application and should be written with care. The techniques of using them are very different from the techniques in unmanaged object-oriented systems, where the destructors free memory and do it in a strictly defined order.
Please see my past answer:
When CLR Do Automatic Memory Management and GC?[
^].
Generally, an application developer should mainly forget the problem of reclaiming the memory of the managed heap, not trying to affect destruction of objects. However, it does not mean that
memory leaks are impossible in .NET. They are quite possible, but are rather the result of bad general code design. You can find some explanations in my past answers:
Memory leak in WPF DataBinding[
^],
Memory management in MDI forms[
^],
Best way to get rid of a public static List Causing an Out of Memory[
^],
deferring varirable inside the loop can cuase memory leak?[
^],
Garbage collectotion takes care of all the memory management[
^].
And finally, how to explain the destructors vs.
Finalize. The idea is this: "destructor" is a method of some OOP languages, something traditional for OOP, by destructors may or may not present in each and every .NET language. The method
Finalize is the method which actually exists in
System.Object, something which exist on a lower level due to the CLI design. You cannot access it directly in C#, where you should use destructor syntax. This is explained here:
http://msdn.microsoft.com/en-us/library/0s71x931.aspx[
^].
For a record: even in C#, you can actually reach the
Finalize method using reflection. You can try it.
Good luck,
—SA
Submit an article or tip