前段时间去鸟国出差颠倒黑白碌碌无为疏于写博请大家理解。下面继续前贴7月《C与C社区混战C#会重蹈覆辙吗》的讨论。这次要谈的是C#的析构器的问题。这是C#中非常华而不实的一个设计不必要且常常误导很多C#er且是.NET性能问题的常见陷阱地带。下面逐项讨论.C#析构器是一个丑陋的语法糖C#析构器即Destructor本质上是对Finalize方法的一个override。既然是对Finalize方法的override那就大大方方让程序员去override 根类Object的Finalize方法好了。可是C#设计师们首先搞了一个析构器接着又在编译器里面把父类的Finalize方法隐藏掉你去override的时候告诉你父类没有Finalize方法。但是编译完后在IL代码中又告诉你override了父类中的Finalize方法而你写的析构器却不翼而飞我在编程语言历史上看到很多语法糖有些语法糖华丽有些语法糖冗赘。但是还从没见过如此弯弯绕的语法糖2. C#析构器偏离了析构器原有的意思析构器自在各编程语言中造始便有以下两大基本含义(a) 回收对象内部开销的动态内存以及各种资源(b) 回收具有确定性时刻比如delete对象时或者栈cleanup时。可是C#将Finalize强扭成析构器后彻底丢失掉前面两大基本含义既无法回收动态内存又无法确定时刻调用只能等GC在猴年马月想起来才调用。而只用于回收资源而即便连这个任务也完成得很差参见3.C#析构器不能完成其设计的初衷。这使得很多沿用以前析构器概念的程序员经常犯如下错误比如class MyClass {object field;~MyClass() { fieldnull; } //既不必要也严重损伤性能}class MyClass {object field;~MyClass() { GC.Collect(); } //既不必要也严重、严重损伤性能}3. C#析构器不能完成其设计的初衷前面说过C#析构器主要用于释放对象的资源非托管资源而非内存。但很不幸对于C#析构器这个唯一的任务它却不能很好地胜任。因为C#析构器也就是Finalize方法是由GC调用的而GC只会在猴年马月想起来才调用回收对象之前的一轮回收往往延误了对象资源的释放——而对象资源是非常昂贵的。 如果真的这样来做的话项目会倒大霉——比如我们以前的一个项目有部分程序员在析构器中释放一些native内存最后导致内存暴涨——用户抱怨下来最后一调试发现原来都是在析构器惹得祸——这些析构器半天没有被GC调用实际上C#设计者在后来意识到这个问题了于是又推出来一个Dispose方法即Dispose模式来让用户显式释放资源。然后又推荐程序员在Dispose里面GC.SuppressFinalize(). 即屏蔽析构器。既然Dispose能将事情确定性地释放非托管资源做好析构器如此没用当初设计它干吗这是再典型不过的多余设计了4. C#析构器会带来严重的性能障碍a) C#析构器会将对象的代标记Generation拖大使得对象更难以被GC回收给GC造成更大性能负担。b) 析构器本身释放资源较晚造成资源紧张影响系统性能。c) 析构器执行需要一个单独的线程开销该线程的执行必须时间很短需要其他线程停止也是一个性能负担。这也是为什么C#推荐实现Dispose不推荐实现析构器的原因。因为析构器的性能代价太大。可能中小项目的开发人员感受不到这一点但我相信做过大型项目的朋友对C#析构器的性能问题会有非常深的体会。