C#会重蹈覆辙吗？系列之4：C#析构器的扯淡设计

前段时间去鸟国出差，颠倒黑白，碌碌无为，疏于写博，请大家理解。下面继续前贴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()   {  field=null;  }   //既不必要，也严重损伤性能

}

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#析构器的性能问题会有非常深的体会。

综上，C#析构器是C#设计师们纯粹为了炫耀自己华丽语法糖、而不小心又失了手艺、一个完完全全扯淡的设计！

面对C#如此拙劣的设计，我真不知道我们技术社区中为什么还有某些人天天捧C#的臭脚，天天揪住其他语言，你为什么没有实现C#这个feature？　你为什么没有实现C#那个function？看你们这些语言多sucks ，我们C#多rocks啊?  

我希望那些捧C#臭脚的人，在捧之前，先看看C#在析构器上以及我之前写的系列帖子上（以及之后将要写的系列帖子上）是怎么sucks的？