引用计数

引用计数是垃圾收集中一种直接方式,其基本策略是每个对象维护一个引用计数,用于表示外界有多少地方引用自己,当有新的引用到这个对象的时候,计数+1,反之一个到这个对象的引用被拆除的时候,计数-1,当计数为0的时候,说明没有人引用这个对象了,这个对象就被销毁。由于直观,容易理解,引用计数在最早实现垃圾收集的lisp,以及早期的java中都使用过,python则是到现在还都一直在用  
注:由于上篇已经论述过的原因,之后的讨论中一律用对象来表示一次申请的堆内存单元,两者是一一对应的  

除了直观,引用计数最大的优势在于,内存的管理是实时的,一个对象只要计数为0,就可以立即被释放,而其他垃圾收集算法往往做不到这一点,实时性带来了很多好处:  

一、对象的生存周期相对来说可控,使得析构函数在一定条件下能起到作用,例如在python中:  
def write_file(s): 
    f = open("a.txt", "w") 
    f.write(s) 
这里无需调用f.close(),因为python采用引用计数机制,在函数返回时f立即释放,在文件对象的析构函数中会执行善后工作,更简洁地可以写成:  
open("a.txt", "w").write(s) 
而在其他语言中,例如java,虽然提供了finalize方法,但由于对象生命周期不可控,因此用得不多,一般也不推荐用  
注意,上面说了,只是在“一定条件”能较好起到作用,比如python写个简单脚本什么的,事实上只要是带垃圾收集的语言,都不推荐用析构函数,python在这方面也有不可控的情况  

二、实时响应,这对于实时系统比较重要,比如一个客户端程序,如果采用标记清除之类的算法,可能需要暂停程序运行,如果内存较小,可能感知不到,但如果稍慢一些,就会卡顿,影响用户体验;另外,有些程序比如游戏,对实时性要求是毫秒级别,占内存又很大,影响会比较严重。这个问题留到后面再说  

三、符合局部性,由于一个对象在需要释放的时候会被立刻释放,整个进程的内存使用会控制在很小的范围,反复释放申请也能充分利用cache等,提高运行效率  

四、研究表明,在分布式系统中,引用计数是非常好的选择  

尽管如此,很多时候引用计数并不被垃圾收集理论(不妨称为“狭义垃圾收集”)承认,或至少不是重点,只是作为一种很原始的方案来介绍,原因是一个致命的弱点:循环引用  

引用计数机制的垃圾回收,是需要对象的引用计数为0,但是存在一种情况,有一些对象从根集无法到达,即已经是垃圾了,但是它们之间互相引用,形成带环的有向图,这种情况下,引用计数机制无能为力,比如python中:  
class A: 
    pass 
a = A() 
b = A() 
a.b = b 
b.a = a 
del a, b 
执行完del后,根集只有一个A(python的类也是对象),这个忽略,而A的两个实例互相引用,因此它们的计数都不为0,这就造成了内存泄露,还有更小的环,自己引用自己:  
a = A() 
a.a = a 
当然可以想见,更大和更复杂的环,或带环有向图是可能的  
关于循环引用问题的解决,一般是引入追踪式垃圾回收机制来辅助解决,关于如何结合的问题,后面再专门讨论  

如果不考虑循环引用,或可以辅助解决,则引用计数机制就是一个完整可行的垃圾回收机制了,但从实用角度讲,它还有一些其他缺陷,不过这些缺陷一般来说不是那么严重  

一,虽然引用计数的机制很容易理解,但不代表做起来简单,这里的问题是,引用计数和程序执行耦合太紧密了,实现虚拟机时,每次赋值(包括传参数等),计算都要正确更新,这无疑是很繁琐的,更大的麻烦是,出错成本和风险不成比例,很可能一个很小的失误就造成悬空指针或内存泄露,而且还很难调试,找这类bug基本是大海捞针,最典型的例子就是写python的C扩展,必须仔细维护引用计数,防止出现问题,因此我一般都尽量用接口,哪怕慢一点  
到了C++中,这个问题有了缓解,只需要写好一个智能指针各种情况(构造,拷贝构造,赋值等)的实现,编译器会在对应的地方对这些方法自动触发,就避免了手工维护引用计数的麻烦,不过,这个方式和下面说的这条有些冲突  

二、维护引用计数需要额外开销,后面会看到,跟踪式垃圾收集消耗的时间一般和内存中对象数量相关,而引用计数消耗的时间和计算量相关,因为每次赋值甚至计算,都会频繁更新计数,每次虽然只是做加减和判断,积少成多也很可观了  
为缓解这个问题,可以结合实际代码和虚拟机实现,优化掉不必要的引用计数,例如栈虚拟机中计算c=a+b:  
load a //a->ref++,为和源语言的属性区别,用->符号表示内部属性 
load b //b->ref++ 
add //top=a+b,a->ref--,b->ref--,top初始ref为1 
store c //c->ref--,先拆除c原先的引用,top->ref++,c=top,top->ref-- 

如果严格按照规定实现,引用计数的变化应该是按上面的注释进行,经过分析可以发现,其中很多操作都是不必要的,比如说最后的store,可以看做是把top“移动”给c,而不是先复制再删除,因此top->ref先加再减就省了;再进一步,a和b入栈做运算也是先加后减,如果a和b不会被其他线程拆除引用,也可以省略  
函数调用也有类似的情况,由于调用栈是严格后进先出:  
func f(): 
    a = 1 
    g(a) 

由于a是局部变量,需要等到f结束,引用计数才会为0,那么在g的执行中,a肯定不会被释放,因此这个传参也可以优化,即调用g和从g返回时,a的引用计数都不变  
但是,做这种优化是比较麻烦的,需要考虑各种情况,比如上面的f中调用的g(a+1),则临时对象的引用计数也需要处理,另外,也不能用上面说的C++的智能指针,需要自己手动维护引用计数  
其实从实际来看,这个问题并没有想象中那么严重:  
1 很多高级语言在虚拟机解释执行,本身速度就比较慢,维护引用计数的消耗不是那么明显  
2 如果换用简单的追踪式垃圾收集机制,的确可以省下这个消耗,但是为了缓解简单的追踪收集引入的卡顿问题,改进为短停顿收集的时候,对于每次引用的拆除和建立也都是需要维护工作的  
3 虽然引用计数的消耗和计算量相关,但这个额外附加的时间是倍数级别的,不会影响程序本身的复杂性,比如cpu消耗从60%涨到70%,那多投入一点硬件,在工程上也能接受  

三、引用计数本身是一个整数,这个整数的范围如果越界,可能造成一些意想不到的后果,而如果用比较长的整数类型,则又耗费内存空间,不过这个问题在现在看来不是很严重,因为现在一般用32位int做计数,只有在超出21亿多个地方引用一个对象的时候才会溢出,如果不是变态程序,基本不会出问题  

四、如果一个对象是容器,则当这个对象的引用减为0的时候,释放之前会对它所引用的对象做计数减一的操作,伪代码表示:  
void dec_ref() 
{ 
    this.ref --; 
    if (this.ref == 0) 
    { 
        for item in this 
        { 
            item.dec_ref(); 
        } 
    } 
    delete this; 
} 

这里出现了递归调用,有些时候,这个调用可能会很深,例如一个很长的单链表,如果栈空间不够,搞不好就崩溃了,这不是危言耸听,linux下栈空间一般8M还好点,vs默认只有1M,递归深度很有限,一般写C++的时候,如果习惯在析构函数里面释放空间,也可能出现这个问题;另外,一次释放这么多对象也是耗时的,虽然大多数情况下引用计数的实时性表现很好,但如果需要释放的东西太多,也会造成卡顿  
这个问题可以通过一个专门的释放器来解决,即当一个对象的引用计数为0时,将其交给释放器,在释放器中可以通过BFS之类的算法来逐步释放空间,避免栈溢出和卡顿,在跟踪式垃圾回收机制中,也有类似的渐进式
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值