C#会重蹈覆辙吗?系列之4:华而不实的C#析构器

前段时间去鸟国出差,颠倒黑白,碌碌无为,疏于写博,请大家理解。下面继续前贴7月《C与C++社区混战,C#会重蹈覆辙吗?》的讨论。这次要谈的是C#的析构器的问题。这是C#中非常华而不实的一个设计,不必要,且常常误导很多C#er,且是.NET性能问题的常见陷阱地带。下面逐项讨论:

 

1.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#设计师们纯粹为了炫耀自己华丽语法糖、而不小心又失了手艺、一个拙劣的设计。

 

[ Update: ] 听从网友的建议,把文章中“脑抽型、臭脚、sucks”等“骂街”的话删除掉了。写这些“骂街”的话实在是昨晚文章写到深处,肝火旺盛,想到某些言论,情不自禁而已。并非我就是“泼妇”,今天一看自己昨晚的言论确实火力太猛,接受大家的意见,改正语言风格,希望下面坚持“技术讨论不骂街“的原则。如果我有时候情不自禁做不到,希望大家监督指点,我会及时改过自新,重新做人:)  

posted on 2010-08-30 23:21 firelong 阅读(...) 评论(...) 编辑 收藏

导航