C # Will it repeat the same mistakes? Series 4: flashy C # destructor

Some time ago, I went on a business trip to the bird country, turning black and white upside down. I am not doing anything, so I am not writing blogs. Please understand. Next, we will continue posting C and C ++ in July.CommunityIn melee, Will C # repeat the same mistakes? . This is about the C # destructor. This is a very flashy design in C #. It is not necessary and often misleading many C # er systems. It is also a common trap of. NET performance problems. The following items are discussed one by one:

 

1. C # The parser is an ugly syntactic sugar

 

The C # destructor (destructor) is essentially an override For the Finalize method. Since it is the override of the Finalize method, letProgramThe Finalize method of the member to override the root class object is good. However, the C # designers first built an destructor, and then hidden the Finalize method of the parent class in the compiler (when you override, tell you that the parent class does not have the Finalize method ). However, after compilationCodeOverride tells you the Finalize method in the parent class, but the Destructor you write is missing!

 

OnProgramming LanguageThere have been a lot of syntactic sugar in history, some of which are gorgeous and some are redundant. But I have never seen such a curved syntactic sugar!

 

2. C # The parser deviated from the original meaning of the parser

 

Since the beginning of each programming language, the parser has the following two basic meanings:

(A) reclaim the dynamic memory and various resources of the object's internal overhead.

(B) reclaim deterministic moments, such as when a delete object or when a stack is cleanup.

 

However, after C # Turns finalize into a destructor, the previous two basic meanings are completely lost, which means that dynamic memory cannot be recycled, it cannot be called at any time (it can only be called after the GC is remembered by the monkey year and month ). Instead, it is only used to recycle resources (even if this task is still poorly completed, see the original intention that 3.c# destructor cannot complete its design ). This makes the following mistakes frequently made by many programmers who have followed the previous destructor concepts, for example:

 

Class myclass {

Object field;

~ Myclass () {field = NULL;} // neither necessary nor seriously damaging Performance

}

 

Class myclass {

Object field;

~ Myclass () {GC. Collect ();} // neither necessary nor seriously damaging Performance

}

 

 

3. C # The parser cannot fulfill its original design intention

 

As mentioned earlier, the C # destructor is mainly used to release object Resources (non-managed resources), rather than memory.

 

However, unfortunately, the only task of the C # destructor is not competent. Because the C # destructor (that is, the Finalize method) is called by the GC, And the GC will only be called after the monkey (a round of collection before the object is recycled ), the release of object resources is often delayed-and object resources are very expensive. If this is the case, the project will be very moldy-for example, some programmers release some native memory in a previous project, this eventually led to a high memory usage-the user complained, and the last debugging found that it was originally caused by the Destructor-these Destructors were not called by GC for half a day!

 

In fact, the C # designer later realized this problem, and then introduced a dispose method (that is, the dispose mode) to allow users to explicitly release resources. Then, we recommend that you use GC. suppressfinalize () in dispose to block the destructor.

 

Since dispose can do a good job (releasing unmanaged resources with certainty), it is useless for the destructor. What was it designed at the beginning? This is a typical redundant design!

 

4. C # The Destructor will bring serious performance barriers

 

A) C # The Destructor will drag up the object generation mark (generation), making it more difficult for the object to be recycled by GC, causing a greater performance burden on GC.

B) The Destructor itself releases resources late, causing resource shortage and affecting system performance.

C) The execution of the Destructor requires a separate thread overhead. The execution of this thread (which must take a short time) requires other threads to stop, which is also a performance burden.

This is also why C # recommends implementing dispose and does not recommend implementing the destructor. Because the Destructor has a high performance cost. Developers of small and medium-sized projects may not feel this, but I believe that those who have worked on large projects will have a deep understanding of the performance of the C # destructor.

 

In summary, the C # parser is a C # designer who simply wants to show off their own rich syntactic sugar, accidentally lost their craft and a poor design.

 

[Update:]Follow the suggestions of netizens andArticleIn "brain pumping, smelly feet, sucks" and other "street abuse" words deleted. If I write these "street abuse" words, I wrote a deep article last night. I was so angry that I couldn't help thinking of some comments. I am not a "Tub". Today, I saw that my speech last night was too vigorous. I accept everyone's opinions and correct the language style. I hope that the following principle will be adhered to: "No street abuse in technical discussion. If I can't help myself sometimes, I hope you can supervise and give me some advice. I will change my mind and be a new person in time :)