CSDN博客

img Elminster

RAII和垃圾收集(下)

发表于2004/2/18 11:24:00  2066人阅读

上回说到,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++ 中具体实现垃圾收集机制也有很多其他的想法,除了“显式析构”之外,我的收集器应该还会有其他方面的优点。当然,这是其他文章的内容了。

好,大致就是这样,希望大家多提意见。如果哪位对实现垃圾收集器这个具体工作有兴趣,请来这边坐坐:
http://www.allaboutprogram.com/bb/viewtopic.php?t=1520

0 0

相关博文

我的热门文章

img
取 消
img