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 阅读(13394) 评论(117) 编辑 收藏 举报