Be careful when writing the terminator code

. Although the object terminator in the net language can be compared with the object Releaser in common object-oriented languages, it is quite different, some of its characteristics sometimes bring great flexibility to our code, but sometimes it will become a harmful trap. Therefore, when we have to use the Terminator, we must be careful when writing the terminator code.

1. The Terminator is called only when GC is used for garbage collection. It is usually difficult to determine its call time in the program.
This is highlighted in almost all documents about the Terminator, which is also the biggest reason for not recommending code cleanup in the Terminator. Introducing the dispose mode is a common alternative.. Net class library can be seen everywhere.

2. The Terminator cannot be used on valuetype.
The Terminator code is not executed when all valuetype objects are recycled. For example, a Terminator is defined in a struct object (in some cases.. Net Language), The Terminator will not be executed by GC.

3. After the Terminator is called, the object is not reclaimed, but will be truly released in the next garbage collection process.
After GC starts the garbage collection process, it will scan all the objects that are currently being effectively referenced, that is, "accessible" objects, and Mark and move these objects, in this way, the remaining objects are so-called "junk" objects. Without the terminator mechanism, GC only needs to directly release these memories, but this is not the case, GC maintains a "list of all Terminator objects ", after confirming the "spam" object, remove the "spam" objects containing the terminator from the list and put them in a queue "prepared to execute the Terminator, this releases the "junk" objects that do not contain the Terminator. In this way, the objects that contain the terminator only execute the terminator code in this round of cleanup. They will be released only in the next garbage collection process.
Imagine that if the discarded object uses a large amount of memory (such as a dataset) and defines a Terminator, in this case, at least two rounds of garbage collection may take place to release the memory it occupies. In some cases, this has a huge impact on performance.

4. The Terminator can be suspended.
You can call GC. suppressfinalize (Object OBJ) to cancel the terminator of an object.
Why does this feature exist? I think it should be to solve the situation mentioned in the third point above. Let's look at such a piece of code.

Public class disposableobject: idisposable
{
Protected virtual void dispose (bool disposing)
{
}
Public void dispose ()
{
This. Dispose (true );
GC. suppressfinalize (this); // cancel the Terminator
}
~ Disposableobject ()
{
This. Dispose (false );
}
}
This should be Microsoft's Recommended Practice for implementing the dispose mode. It ensures that GC will not call the object Terminator after we clean the object through its idisposeable, in addition to avoiding the dispose (bool) in addition to repeated methods, this may greatly improve the performance. If we do not use this interface to clean up objects, the Terminator will call dispose (bool) for cleanup.
However, this is not perfect. disposableobject requires the successors of this class to understand the implementation of its parent class clearly. If a subclass of disposableobject implements public class myobject: disposableobject
{

~ Myobject ()
{
Destroynativememories ();
}
}

Some users of the myobject class use this class.

Using (myobject OBJ = new myobject ()){
OBJ. dosomething ();
}

In this way, they will get Memory leakage. Note that many classes in the. NET class library are similar to the disposableobject implementation, such as system. Windows. Forms. form.