Programming
The same point for Finalize and Dispose (bool disposing) and Dispose ():
All three are intended to release unmanaged resource services.
Different points for Finalize and Dispose () and Dispose (bool disposing):
The
finalize is a mechanism provided by CRLs that guarantees that if a class implements a Finalize method, then when the class object is garbage collected, The garbage collector invokes the Finalize method. Developers of that class must handle the release of unmanaged resources in the Finalize method. But when will it be called Finalize is determined by the garbage collector, and the consumer (customer) of the class object is out of control. Thus, it is not possible to release valuable unmanaged resources in a timely manner. Because unmanaged resources are more valuable, this can degrade performance.
Dispose (bool disposing) is not a mechanism provided by a CRL, but merely a design pattern (as a method of a IDisposable interface), and its purpose is to allow the consumer (customer) of the class object, after using the class object, You can manually invoke the release of an unmanaged resource in a timely manner without waiting for the object to be garbage-collected at that point in time. Such developers simply migrate the code originally written in finalize to release the unmanaged resource into the Dispose (bool disposing). In Finalize, it is OK to simply invoke "Dispose (false)" (explain why you passed false).
This time we may be puzzled, why do we need a Dispose () method? Is there only one Dispose (bool disposing) or only one Dispose ()? The
answer is:
There is only one Dispose (). Why not? Because if there is only one Dispose () without Dispose (bool disposing) method. It is not possible to determine whether the method was invoked by a client or by the garbage collector through finalize calls in code that handles the release of unmanaged resources. Unable to implement judgment if the client calls manually, then the garbage collector does not want to call Finalize () Call the Gc.supperfinalize method). Another possible cause (: We know that if the garbage collector is called through Finalize, we might also reference some other managed objects in the release code, at which point the managed objects may have been garbage collected, This can result in unpredictable execution results (never refer to other managed objects in finalize).
So it does require a bool disposing parameter, but if there is only one Dispose (bool disposing), then for the customer, there is a funny requirement that Dispose (false) has been used by finalize, The customer must be called in Dispose (true), but who can guarantee that the customer will not call in Dispose (false)? So here is a design pattern: overload to implement Dispose (bool disposing) as protected, The Dispose () implementation is public, so that the client can only call Dispose () (internal call Dispose (true)/description is a direct call from the customer), and the client cannot invoke Dispose (bool disposing).
Examples are as follows:
public class Baseresource:idisposable
{
The destructor automatically generates a Finalize method and a call to a finalize method of the base class. By default, a class is not destructors, that is, when an object is garbage collected, the Finalize method is not invoked
~baseresource ()
{
To keep your code readable and maintainable, don't write code to release unmanaged resources here
Must be called in Dispose (false) to false to tell the Dispose (bool disposing) function to be called from the garbage collector when the finalize is called
Dispose (FALSE);
}
cannot be called directly by the client
If disposing is true, then this method is called directly by the client, and both managed and unmanaged resources can be freed
If disposing is false, then the function is called from the garbage collector when calling Finalize, and no other managed object should be referenced at this time so, only unmanaged resources can be freed
protected virtual void Dispose (bool disposing)
{
So this method is called directly by the client, so both managed and unmanaged resources can be freed
if (disposing)
{
Releasing managed resources
Othermanagedobject.dispose ();
}
Freeing unmanaged Resources
Dounmanagedobjectdispose ();
This method is called directly by the customer, telling the garbage collector to purge itself from the finalization queue, thereby preventing the garbage collector from invoking the Finalize method.
if (disposing)
Gc. SuppressFinalize (this);
}
Can be called directly by the client
public void Dispose ()
{
Must be called in Dispose (true) to tell the Dispose (bool disposing) function to be called directly by the client
Dispose (TRUE);
}
}
The above example achieves the purpose:
1/If the customer does not invoke Dispose () and fails to release the managed and unmanaged resources in a timely manner, there is also a chance to execute Finalize () and release the unmanaged resources at garbage collection time, but cause an idle waste of unmanaged resources not released in time
2/If the customer invokes Dispose (), the managed and unmanaged resources can be freed in time, then the Finalize () is not executed back when the object is garbage collected, improving the efficiency of the unmanaged resources and improving the system performance
You can refer to the SqlConnection object's new, Open, close (internal call Dispose ()) experience to deepen their understanding. Thank you!