The destructor of a class that implements IDisposable will not be called

[Jun-GY]

The destructor of a class after implementing IDisposable is never called. Does this mean that the instance GC of this class will not release resources? I'm not sure if this guess is correct? The attached file is a test case. Currently, I am encountering the problem that resources cannot be released in my project. The memory continues to grow and the GC does not release related resources. The code is similar to the test case. I don’t know how to solve it now?

Wpf.ResourceCleanup.zip

[qrli]

C# destructor maps to finalizers of dotnet runtime. Nowadays, finalizers are useless most of the time. Finalizer have many issues, e.g.:

• It is not guaranteed to be called. E.g. when Environment.Exit() is called or process crashes, or when some finalizer blocks, the ones after it won't have a chance to run.
• It is not guaranteed when it is called. The GC decides when to call them, and may well delay their execution to keep higher priority code runs.
• It is not guaranteed in which threads they are run. Typically it is different thread than the object is created, while a lot of native code resource requires the destruction call to be run in the same thread as creation.

So, for most developers, forget about finalizer, you won't need it. You don't need finalizer for managed objects. For the rare cases where you do want something like finalizer but does its job, e.g. wrapping native code resources/objects, you should use SafeHandle instead, which utilizes something called Critical Finalizer internally. Note it is not for average developer; there are many rules and cautions to really make it work as expected.

[Jun-GY]

Thank you qrli.

Are the implementation guidelines for the IDisposable interface applicable to internal data clearing operations of ordinary classes? Will ordinary classes implementing the IDisposable interface affect the GC's release of class resources? I'm not sure about this? At present, I can only determine through the destructor, the difference in appearance to GC between implementing the IDisposable interface and not implementing the IDisposable interface.

[yaakov-h]

IDisposable.Dispose should be called when you're finished with the object.

A finaliser gets called (if it gets called) when the runtime is finished with the object.

IIRC, the GC doesn't see a difference between disposable and non-disposable objects by default - however this changes if you follow the old IDisposable guidance and call GC.SuppressFinalize(this) from the Dispose() method.

[qrli]

@Jun-GY IDisposable is useful for releasing resources as soon as possible, so it is a good practice to dispose disposable objects when you finish using them. (BTW, there is a not-so-common special case, typically in GUI apps, where IDisposable is also used to unsubscribe events - if you fail to dispose them, it may lead to dead objects react to events and then throw.)

If you write a class which has disposable fields, your class should also implement IDisposable so that your Dispose() calls those fields'. However, in this case, you don't really need the destructor/finalizer. Especially, you should NOT call Dispose inside destructor/finalizer - finalizers should avoid calling into other objects because the other object may already have its finalizer executed. Here nothing is related to GC, except the hidden internal SafeHandles of those native object wrapper objects, which will act as the last safe net in case you fail to dispose them.