I am little bit confused about use of destructor in c#. In my knowledge we can't call destructor acording to my wish it will call automatically before garbage collector for performing some work over class (object) so i want to ask if we are using destructor in c# then whe we need to garbage collector. As i know that destructor can take care of memory then why we need to garbage collector ?
6 Answers
Everybody thinks about garbage collection the wrong way:
A correctly-written program cannot assume that finalizers will ever run.

- 288,378
- 40
- 442
- 569
-
+1 Pretty much the best answer so far, and the only one that's actually correct. At best, you put a call to Dipose() in your finalizer, in case Dispose() wasn't called manually by other code in your program. – siride Sep 06 '10 at 05:04
-
1Also the article linked by Unmesh is a very god resource, http://msdn.microsoft.com/en-us/magazine/cc163392.aspx. There are many other articles on web that mention the `Dispose(bool disposing)` pattern w/o actually explaining the difference between 'native' and 'managed' resources. I've seen plenty a classes that were needlessly implementing the pattern to dispose *managed* resources. – Remus Rusanu Sep 06 '10 at 05:15
-
Ahhh... here I was thinking about Garbage Collection as collection of garbage when I should've been thinking about it as putting out fires. Joking aside, I'm not convinced the article really helps, its better to think of closing streams and files as a business logic requirement than a resource requirement (which ultimately is up to the OS in any case) – CurtainDog Sep 06 '10 at 05:28
-
The closing streams and files duty in C# belongs to the `IDisposable` and `using` pattern, not to finalizers and destructors. – Remus Rusanu Sep 06 '10 at 05:52
-
the above link is not working now, can anyone help me out?? – Radha Manohar Jan 10 '20 at 09:32
I think based on reading your almost duplicate topic that you don't have a well understanding of how the Garbage Collector works. In a very blunt and brief manner, it is its own service that runs in the background, it tracks and frees memory for unused and disposed objects throughout the entire lifetime of your application. Realistically, you should never have to call the GC yourself, unless in very rare and specific cases.
The desctructors are used to clean up and free unmanaged resources that cannot be freed by the Garbage Collector, see this MSDN page for more information on destructors.

- 1
- 1

- 13,558
- 5
- 50
- 76
-
1+1 for speaking out loud that the best advice is probably to brush up his knowledge about memory management, garbage collection and native resources/dispose in .NET – Jim Brissom Sep 06 '10 at 05:11
It would also be useful to read about the correct way to implement IDisposable pattern. There is much more to it than what we think -

- 9,256
- 4
- 38
- 51
The destructor is not for cleaning up managed memory. That is what the garbage collector is for. The destructor is for cleaning up other resources such as handles.
I recommend that you take a look at CLR via C# for details on how this works.

- 114,645
- 34
- 221
- 317
I think the confusion here comes from the fact that you can dispose of objects both deterministically and non-deterministically (i.e. when the GC gets round to doing it).
To answer your questions as to why we need a GC at all I would say, even putting aside memory leaks, that GCs are quite performant, and a having a requirement of immediately reclaiming memory might actually lower the total performance of the system. Its a similar argument to the single- vs multi- threaded debate.

- 3,175
- 21
- 17
Destructors in C# should be used very rarely. However, in some cases you have no choice.
For example, if you have a singleton class for logging and from performance reasons you cannot use autoflush, flushing a buffer during finalization of the singleton should be considered.

- 439
- 3
- 4