SafeHandle and Destructors

SafeHandle is a mechanism of destruction, and what is the difference between her and the destructor.

The first step is to understand the destructor. Destructors are not sequential in. NET, so you cannot assume that the destructor of another object runs after you, even if it is your member! If your members also have destructors, then what can you do and what should not be done?

First, you should not assume that it did not clean up and try to clean it up. It is reasonable that it should implement the Dispose mode on its own, and you can call its Dispose () function in the Dispose (false) paragraph. Because dispose can be re-entered multiple times, there is no problem. Of course you can ignore him, too.

Second, a. NET object that implements Dispose, what should the external look like? The resource it controls should not be considered an unmanaged resource, since he implements Dispose, which is "self-managing", and should therefore be called in the Dispose (false) paragraph. This is my understanding of the dispose pattern. The dispose pattern is divided into two types of resources, one for hosting and one for unmanaged. Hosting and unmanaged are not purely from the. NET perspective, but should be understood as the difference between "self-management" and "other object management". Your object opens the file itself and shuts itself down, while the other objects, including the member objects, are controlled by the resources they control and, in their current position, are "managed".

The advantage is that I can control the timing of each object member that implements the Dispose mode separately, and Dispose (false) is a destructor that can be used as a defensive code to help me clean up the forgotten object resources. Of course there's a downside, and if you want Dispose to shut down all resources, it doesn't have that effect. But there are two implementations of Dispose, one that does not have destructors to combine, can adopt this unified pattern, and does not need to rely on defensive code, of course, this cleanup task will be given to you.

Then Safehandle,safehandle is said to have been optimized, but it will not be the first to run in the destructor phase, which is the case in my test. So I don't know where the optimization is. Just add a pattern, more rudder control than the destructor, after all, is an externally independent class, and the system has provided the appropriate subclass for a variety of resources, but not for the COM object resources.

In general, the best practices are:

1. If the SafeHandle sub-class has system resources, such as handles, unmanaged memory, and so on, use SafeHandle mode.

2. If the child member correctly implements Dispose, use the dispose pattern with the destructor.

3. If the child member does not implement Dispose, but controls the associated resources, that is, you are responsible for the explicit control of the sub-object related resources, do not use the destructor cleanup, because the destructor phase, the child member may have been associated with the resources released (not necessarily in the right way, just to lose control of resources), You can no longer clean up. Because the GC's destructor invocation order for arbitrary objects is indeterminate. (This can only require you to properly call Dispose in the programming phase and never forget the call, otherwise there is a resource leak.) This is how COM for. NET is designed)

4. In other cases, you can use destructors for defensive programming.

The implementation of 5.dispose should be standardized.

What to note about the specification of Dispose, add here:

        private bool Disposedvalue = false;                To detect redundant calls protected virtual void Dispose (bool disposing) {if (!disposedvalue) {                    if (disposing) {//TODO: Releases the managed state (managed object). This should contain the dispose//safehandle of the member object.                                                        Dispose ();                }//TODO: Frees unmanaged Resources (unmanaged objects) and replaces finalizers in the following.                TODO: Set the large field to null.                Here is the release of some of the resources of self-management closefile ();                App = null;            Disposedvalue = true;         }}//todo: Replaces finalizers only if the above Dispose (bool disposing) has code to release unmanaged resources. ~excel () {//Do not change this code.            Put the cleanup code in the above Dispose (bool disposing).        Dispose (FALSE);        }//Add this code to properly implement the disposal mode. void IDisposable.Dispose () {//Do not change this code.            Put the cleanup code in the above Dispose (bool disposing).            Dispose (TRUE); TODO: If within the aboveJongzhong replaces the finalizer, uncomment the line. If the Dispose (false) Paragraph has no content, you can add the following statement, rather than comment out//The statement is intended to cancel the execution of the destructor. Assuming there is no content and no need to write destructors, it is superfluous GC.        SuppressFinalize (this); }

SafeHandle and Destructors