The Consequences of NOT Properly Implementing IDisposable

Question

I like how to implement IDisposable ..

However, I do not quite understand exactly what consequences cannot be implemented properly. Is this the case when unmanaged resources will never be cleaned up, which will lead to memory leaks or, in the end, memory will be restored, but not in a timely manner?

Answer 1

It depends.

If the object in question cannot implement IDisposable, but still implements the finalizer correctly, the resources will ultimately be cleared.

However, if it implements the finalizer incorrectly, and it wraps an unmanaged resource, this resource will leak. This is most often a resource leak (ie, a HANDLE leak stored as IntPtr) is more than a traditional “memory leak” (although, of course, the object pointed to still uses memory).

Will the memory be eventually recycled?

One point here ... IDisposable has nothing to do with memory - it's about resources. These resources often use their own memory, but implementing IDisposable does not cause the garbage collector to recover memory faster.

Answer 2

It depends entirely on what the implementation is, of course.

Incorrect placement in SqlTransaction can lead to excessive long-term blocking, for example, by the impact of several computers and users. Incorrect placement on SqlConnection can lead to saturation of the connection and inability to connect. These are not just memory problems (etc.).

IIRC the missing graphic object (pen / brush / all) disposed of the person responsible for the VS failure error - the GC did not occur because there was no pressure in the memory, so instead it just saturated the GDI descriptors and broke.

An invalid file / stream dispose may cause exceptions due to the inaccessibility of the file for reading / writing - potentially data loss.

If unmanaged resources are not handled properly, anything is possible.

Answer 3

Instead of thinking in terms of some vaguely defined “resources,” think of IDisposable as meaning “This object manipulates something outside of itself (and possibly even outside of the computer!) In a way that needs to be cleaned up, whereas information, necessary for such cleaning still exists. " The finalizer, who shoots essentially, says: "Nobody uses this material anymore, and I'm the only one who knows about it, I’d better clean it because nobody is going to."

It is dangerous to assume that finalizers will worry about things; while many objects can be safely left behind, many others cannot. In some cases, it will be easy for an object to detect that it has been left and cleaned accordingly. In some other cases, it can be as difficult as being impractical. Consider an object that must count how many times the word “quack” appears in a long-term data stream. If the creator of the object has forgotten about this, and no one is going to request an invoice, the object may also leave. Unfortunately, since the data stream contains a reference to the counting object (to tell it when the data arrives), the counter object will not disappear. If the code creates a counter, then forgets about it, then creates another, forgets about it, etc. This can become an unlimited memory leak.

Answer 4

A class that contains unmanaged resources must ensure that they are cleared during finalization. However, this only happens when the garbage collector approaches it.

Do not invoke the Dispose tool while waiting for the garbage collector to consume memory until resources are available.

Answer 5

The last of two. Just not timely.

The importance of this depends on the resources you allocate. That is why you are most likely to see IDisposable interfaces on objects that open files and link to other, more crticital, resources.

Answer 6

Yes, unmanaged resources will never be released. (It is assumed that the considered types of IDisposable does not implement "standby" finalizer. If they do, the finalist must deal with things ... in the end.)

However, these are not just unmanaged memory allocations that you need to worry about; these are any unmanaged resources. For example, if you do not properly manage database connections, you may find that the connection pool is quickly exhausted.

Answer 7

Another potential problem with the incorrect implementation of a one-time template is that it's very easy to accidentally call. Dispose () more than once. If your Dispose method does not check sequential calls for it and (for example) tries to free an unmanaged resource more than once, you may get some fatal error or unexpected behavior.