现在的位置: 首页 > 综合 > 正文

RAII和垃圾收集GC

2014年02月13日 ⁄ 综合 ⁄ 共 7038字 ⁄ 字号 评论关闭

RAII和垃圾收集GC

 

JavaEyeutensil按:此文转自CSDN文档中心,作者是Elminste。看了这篇文章才知道,之前我称之为像栈一样令人放心的析构函数并非常喜爱的C++特性,原来名为RAII(资源获取即初始化,Resource Acquisition Is Initialization),而且发现原来它和GC并不是我想象的那么水火不容。这篇文章,在我看来,进一步说明了Java因为GC而对面向对象的思想所进行的阉割,而且正是Java写的程序常常因为资源泄漏问题而崩溃的罪魁祸首(个人观点,请勿扔砖)。

 

先来看一小段代码,它取自Bjarne Stroustrup的演讲“Speaking C++ as a Native”

熟悉C++的朋友对这种简称为RAII的技巧一定不会陌生。简单的说,RAII的一般做法是这样的:在对象构造时获取资源,接着控制对资源的访问使之在对象的生命周期内始终保持有效,最后在对象析构的时候释放资源。借此,我们实际上把管理一份资源的责任托管给了一个对象。这种做法有两大好处:

第一、我们不需要显式地释放资源。以上述代码中的函数f为例,我们不必担心忘记关闭文件的问题。而且,即使是函数f的控制结构发生了改变,例如在函数中间插入return或者抛出异常,我们也能确定这个文件肯定会被关闭。特别是在异常满天飞的如今,RAII是实现异常安全的有力武器。类似的,如果某个类C包含一个File_handle成员,我们也不必担心类C的对象会在销毁时忘记关闭文件。

第二、采用这种方式,对象所需的资源在其生命期内始终保持有效——我们可以说,此时这个类维护了一个invariant。这样,通过该类对象使用资源时,就不必检查资源有效性的问题,可以简化逻辑、提高效率。

好,介绍完了RAII,下一个要出场的角色是大名鼎鼎的垃圾收集(Garbage Collection,下面简称GC)。随着Java的流行,GC已经被越来越多的人所接受,下面我简单介绍一下GC的运行机理。

首先引入几个术语:在GC的语境中,对于程序可以直接操纵的指针值(例如,保存在局部变量或是全局变量中的),我们称之为;假设对象A1保存了一个指向对象A2的指针,对象A2保存了指向对象A3的指针,我们称A1->A2->A3构成了一条指针链”——当然,指针链可以任意地长;假设从程序中的某个根出发,通过一条指针链能够到达对象A,那么我们认为对象A存活的,否则,就认为它已经死亡,随时可以释放它占用的内存。

所有GC实现,其运行方式都是检查对象是否存活,并将已经死亡的对象释放,其实现机理一般分为三大类:

一、引用计数(reference counting),这类GC实现为每个对象保存指向它的指针数量,一旦这个数量降为0,就将这个对象释放,小有名气的boost::shared_ptr采用的就是就是这种方式;

二、标记-清扫(mark-sweep),这类GC实现周期性地扫描整个堆,先将其中的存活对象标记出来,然后再将剩下的死亡对象全部释放;

三、节点复制(copying),这类GC实现将整个堆分成两半,并周期性地将存活对象从当前使用的那一半搬到另一半,留在原先位置的死亡对象就自然地被抛弃了。

这三类实现中,引用计数的限制最多(特别是无法回收环形结构),而且一般在效率上居于劣势,应用较少,后两类使用较多。这方面的一些细节,可以参考2003年第1期程序员上的垃圾收集专栏。另外,人民邮电出版社即将推出《垃圾收集》一书的中译本,这本书可以说是目前世上唯一一本关于GC的全面性的专著,对GC有兴趣的朋友可以找来看一下(嘻嘻,打个广告,^_^)。

毫无疑问,对于程序员来说,在分配了内存之后如果能够不必操心怎么释放它,那一定是非常惬意的。更重要的是,程序员们从此可以向悬挂引用和内存泄漏告别了——它们可是程序开发中最令人头痛的bug之一。最后,有了GC的支持,在程序的各个模块之间共享数据变得更容易、更安全,有助于简化模块之间的接口。虽然在GC对效率的影响方面,人们还存在着各种疑虑,但必须承认,GC是一种有价值的技术。

可惜,非常不幸的,现有的GC机制和RAII之间可以说是水火不容——怎么会这样呢?

症结在于这两位对待析构函数的态度不同。回顾我们对RAII的介绍,它的核心内容就是将一份资源托管给一个对象,让资源在对象的生命周期之内均处于有效状态,这样,它就要求资源由对象的析构函数来释放。而问题正是在于,当前现有的GC机制下面,很难提供对析构函数的支持。可能会有人感到奇怪,让GC实现在释放对象的时候调用析构函数不就结了吗?可惜,事情不那么简单。

GC的语境中,像析构函数这样在销毁对象时执行的动作,被称为终结finalization),而支持终结一直是GC实现上的一个难题,因为终结动作很可能给收集工作带来很大的干扰。举例而言,考虑下面这样一个终结动作(这里我采用C++析构函数的形式):

 

假设现在我们有一个wedget对象w,进一步假设在某个时刻,GC机制发现从任何一个根出发,都无法到达w,那么按照定义它已经死亡,可以执行终结动作然后释放了。但是,当我们执行终结动作的时候,w又把指向自己的指针赋给了一个全局变量也就是一个根,也就是重新出现了一条由根出发、可到达w的指针链,这样,按照定义——它又复活了!如果你有心,随便动动脑子就可以想出上述问题的许多变种,其中有一些还可能显得很冠冕堂皇

此时我们该怎么做呢?复活w?那样的话我们还必须复活所有w指向的对象,但要实现这一点很难,这要求我们不能在执行终结动作之前释放任何对象(你无法预先确知终结动作会影响哪些对象),而且可能陷入死循环(执行完终结动作之后,你必须重新确定各个对象存活与否,然后再试着执行终结动作……)。那么我们不复活w?也不好,这样一来global_pointer就成了一个悬挂引用,GC保证的安全性就被捅了一个大窟窿。或者我们禁止在析构函数中出现指针操作?困难,如果析构函数调用其他函数,难道你还能递归地禁止下去?要不我们禁止调用其他函数?咳咳,那这个析构函数根本就无法实现任何实质性的功能,不要提释放资源了。

除去实现上的困难之外,用GC中的终结机制来释放资源还有一个更本质上的问题:执行终结机制的时间是无法确定的。且不说除引用计数之外的GC实现释放对象本来就有相当大的延时,就算将来的实现真的能够保证对象在死亡的瞬间被释放,同样无法满足需求:假设在某一时刻你希望析构某个对象,释放它占有的资源,但只要某处仍然存在一个指向该对象的指针,这个对象就会顽强地生存下去。不妨假设一下,如果这里需要释放的资源是一个计时收费的网络链接,那么……(祝你好运,兄弟!这是你的铺盖卷,^_^

综上,我们已经有充分的理由说,现有GC环境下面根本不可能应用RAII,它们之间水火不容。事实上,像Java那样支持GC的语言,一般都不鼓励你使用终结机制,对象所需的资源必须显式地释放。最简单的,为这个类添加一个close成员函数负责释放资源。

 

这样做有什么缺点呢?对照最初我们对RAII优点的介绍就可以知道了:

 

首先,所有对象需要的资源必须显式地手工释放。拿最初的例子来说,函数f的最后必须加上一句file.close(),而且我们得开始担心函数f控制结构的改变,无论是中间插入return还是可能抛出异常的地方,都必须加上file.close()。针对这种情况,Java等语言一般会支持try...finally这个特征,规定无论因为何种原因离开函数,都必须调用finally代码块中的代码。try...finally确实有效地缓解了这一问题,但是仍然不及RAII方案理想:

一、在撰写try...finally中付出的努力是无法重用的,如果你有10个函数里用了file_handle,你必须把同样的代码写上10遍;

二、确保try块中申请的资源和finally块中释放资源互相配对现在成了程序员的责任,这是多出来的簿记负担,而且一旦出错出现资源泄漏是很令人头痛的——一般来说,这要比内存泄漏隐蔽多了,而且不可能有专门的工具帮忙;

三、如果某个类拥有若干类似file_handle这样的成员,我们必须为这个类也添加一个close函数,并逐个调用成员的close函数(搞不好各个成员释放资源的函数名字还不一样),这也是一个多出来的簿记负担——而且try...finally帮不上什么太大的忙。

其次,由于允许显式地释放资源,对象无法再像以前那样保持所需的资源在其生命期内始终有效这样一个invariant,因此对象中所有使用资源的方法必须检测资源的有效性,用户在使用对象的时候也必须留意资源是否有效(这种错误多半以异常形式呈现)。这不仅使得逻辑变得复杂,而且又是一个多出来的簿记负担——对于每种需要资源的类,用户必须记住它们抛出的代表资源无效的异常是什么。

唔~~到目前为止,似乎形势稍稍有点令人沮丧。RAII是管理资源的利器,而GC提供的方便和安全保证更是诱人之极,但偏偏两者不可得兼。你要么投向GC的怀抱,然后不得不手工管理其他资源,忍受多出来的麻烦和簿记负担;要么放弃GC,老老实实手工管理内存,但却能够在管理其他资源的时候享受RAII带来的方便和安全。你当然可以说世界就是这样的,有时候我们不得不做出权衡,为了得到一些而放弃另一些,只是……有没有更好的办法呢?

 

锵!锵!啪!欲知后事如何,且听下回分解!

 

上回说到,RAII与现有的GC环境互不相容,也提到了问题的症结在于对析构函数的调用。这并非仅仅是一个令人遗憾的巧合,仔细想想不难发现,在这个矛盾背后,实际上是两者在如何看待一个对象这一问题上的分歧。

前面说过,RAII的核心内容是把资源托管给对象,并保证资源在对象生命周期内始终有效。这样,我们实际上把管理资源的任务转化成了管理对象的任务,你拥有对象就等于拥有资源,对象存在则资源必定存在,反之亦然。RAII的全部威力均源于此。这种做法的出发点,用Bjarne Stroustrup的话来说,是“use an object to represent a resource”(引自本文上篇开头所引用的代码中的注释)。换句话说,在RAII的眼中,对象代表了资源,它的行为和状态应该与资源的行为和状态完全一致,所以资源的申请和释放也就自然应该和对象的构造与析构对应起来。对于大多数资源,程序员有权而且需要控制它何时释放,那么很自然的,对于管理这些资源的对象,程序员也就应该有权而且需要控制它何时析构。一言以蔽之,这要求程序员有权控制对象的生命周期。

然而现有的GC环境并不满足上述条件。在本文的上篇中介绍过,对于GC来说,一个对象的生命周期有多长程序员是无权干涉的,任给对象A,它是否存活必须严格地按照是否存在一条从根出发的指针链能够到达A”来判定。在GC的眼中,对象只是一段被分配的内存,而历史已经证明,决定内存何时释放这个任务决不能交给爱犯错的程序员,应该由专门的收集器完成,以确保每个内存回收动作都是安全的。什么?一个对象代表一份资源?哈!我GC大人的眼中只有内存,没有什么资源!

啧啧,两者眼中对象的角色差异如此之大,难怪会水火不容了。不过,这个矛盾真的没有调和的可能吗?倒也不见得。RAII看重对象的语义,要让对象代表资源,因此需要程序员能够控制对象的生命周期,而GC眼中只有内存,反复强调只有让收集器来回收内存才能保证安全,这活不能让程序员来干。因此,要同时满足这两者的要求,对象的生命周期和必须和内存的释放脱钩。这不是什么新鲜想法。事实上,按照C++标准的定义,一个对象的生命周期始于构造函数,终于析构函数,它本来就不是由内存分配释放来决定的,而placement new更是把这一点表现的极为充分,分配内存、构造对象、析构对象、释放内存四个操作清清楚楚、各自独立。至此,我们的解决方案已经呼之欲出了。一方面,我们要把释放内存的责任移交给GC,同时又要允许程序员控制对象生命周期,那么,正确的做法就是……

在现有GC机制的基础上,允许程序员显式地析构对象,同时,若程序试图访问已经析构的对象,将抛出异常。

这初看起来非常荒谬(我已经可以看到台下飞来的无数鸡蛋和番茄……哎哎?!你们真砸啊?),但其实并非如此。首先,内存的分配和释放由GC机制管理,凡是指针可到达的内存总是有效的,因此我们拥有同样的安全性保证——没有悬挂引用和内存泄漏,所以,我们可以放心大胆地在模块之间共享对象,不必操心悬挂引用的问题,也不必担心内存管理的细节弄脏模块之间的接口;其次,由于允许显式析构对象,程序员能够控制对象的生命周期,因此我们可以继续应用RAII“用对象代表资源的语义并享受它带来的便利;最后,试图访问已经析构的对象将会抛出异常,堵上了无定义行为的口子。一句话,现在我们可以把对象放入支持GC的堆里而不必改变它的语义了。

瞧!两边不是合作得很好么?

必须承认的是,要实现这个方案,实际上是非常简单的,但是就我所知,目前并没有任何一个GC环境支持这个做法。这是因为大多数支持GC的语言并没有类似C++中的析构函数这样的语言特征,换句话说,压根没有应用RAII的能力,而C++本身又并不支持GC。嗯嗯,面对这种情况,我决定效法先贤——自己实现一个用于C++的垃圾收集库,用智能指针来实现对指针访问的控制,并提供显式析构的接口。

最后,我来试着回答某些可能出现的质疑:

 

问:显式析构和显式调用close有什么区别?不一样要程序员自己动手吗?

答:有区别。请参阅本文中,关于RAII相对于显式释放资源方案的优势。

 

问:你允许程序员析构对象,那么可能出现指向已析构对象的指针,这和悬挂指针不是一样么?

答:不一样。如果你试图访问已析构对象,只会抛出一个异常(当然,这得通过智能指针来实现),而访问悬挂指针……不用我多说吧?

 

问:(续上)这样一来,通过指针访问对象可能抛出异常,这是原来没有的。

答:这种说法不准确。在现有的GC机制下,对象占有的资源需要调用(例如)close成员函数显式释放,而在调用了close之后,再试图访问这个对象一样会抛出异常,指明使用这个对象所需的资源已经被释放。而且,对于现有的方案,每种对象释放资源的函数可能都不同,标识资源已释放的异常可能都不同,但如果使用显式析构的方案,释放资源的手段是一致的(析构对象),标识资源无效的异常也是一致的(对象已析构),这大大减轻了程序员的簿记负担。

 

问:(再续)但是你多一个检查啊?每个指针访问都需要检查对象是否已析构,效率太低。

答:这种说法也不准确。采用显式调用close释放资源的方案,在该对象内部,每个完成实质性工作(因此需要访问对象所需的资源)的成员函数同样必须检查资源是否有效,也是一个检查。而且,这样的检查程序员需要为每个类分别撰写,而采用上述显式析构的方案,只有智能指针需要做这个检查。

 

问:(再续)你上述两个问题的回答多少有点偏颇吧?并不是对象的每个成员函数都需要访问资源,你上述两个辩解对于不需要访问资源的成员函数是不成立的。而且,也并不是所有的对象都需要管理资源,如果我想在支持GC的堆里放一个int怎么办?这样,可能会抛异常多一个检查无疑是两个很大的缺点了吧?

答:嗯嗯,这可能是最有力的质疑了,我的回答是这样的:我会另外提供一种不支持显式析构的智能指针,它的使用就像传统GC环境下的指针一样,也就没有可能会抛异常多一个检查的问题。换句话说,如果你的对象不管理资源,或者你一定要在资源释放之后还能继续访问对象,用它你可以退回到传统的GC方案去。

 

问:我就是不喜欢你这套想法!有意见吗?

答:……没意见。如果你确实无法接受显式析构的想法,你也可以只使用上面提到的另一种智能指针——嗯嗯,除了显式析构之外,我对于如何在C++中具体实现垃圾收集机制也有很多其他的想法,除了显式析构之外,我的收集器应该还会有其他方面的优点。当然,这是其他文章的内容了。

抱歉!评论已关闭.