Python垃圾回收机制:gc模块

浏览数：29 / 时间：2015年06月08日

在Python中，为了解决内存泄露问题，采用了对象引用计数，并基于引用计数实现自动垃圾回收。

由于Python 有了自动垃圾回收功能，就造成了不少初学者误认为不必再受内存泄漏的骚扰了。但如果仔细查看一下Python文档对 __del__() 函数的描述，就知道这种好日子里也是有阴云的。下面摘抄一点文档内容如下：

Some common situations that may prevent the reference count of an object from going to zero include: circular references between objects (e.g., a doubly-linked list or a tree data structure with parent and child pointers); a reference to the object on the stack frame of a function that caught an exception (the traceback stored in sys.exc_traceback keeps the stack frame alive); or a reference to the object on the stack frame that raised an unhandled exception in interactive mode (the traceback stored in sys.last_traceback keeps the stack frame alive).

　　可见，有 __del__() 函数的对象间的循环引用是导致内存泄漏的主凶。但没有__del__()函数的对象间的循环引用是可以被垃圾回收器回收掉的。

如何知道一个对象是否内存泄露掉了呢？

可以通过Python的扩展模块gc来查看不能回收掉的对象的详细信息。

例

例1：没有出现内存泄露的

import gc
import sys

class CGcLeak(object):
    def __init__(self):
        self._text = ‘#‘ * 10

    def __del__(self):
        pass

def make_circle_ref():
    _gcleak = CGcLeak()
    print "_gcleak ref count0: %d" %(sys.getrefcount(_gcleak))
    del _gcleak
    try:
        print "_gcleak ref count1 :%d" %(sys.getrefcount(_gcleak))
    except UnboundLocalError:           # 本地变量xxx引用前没定义
        print "_gcleak is invalid!"
def test_gcleak():
    gc.enable()                         #设置垃圾回收器调试标志
    gc.set_debug(gc.DEBUG_COLLECTABLE | gc.DEBUG_UNCOLLECTABLE | gc.DEBUG_INSTANCES | gc.DEBUG_OBJECTS)

    print "begin leak test..."
    make_circle_ref()

    print "\nbegin collect..."
    _unreachable = gc.collect()
    print "unreachable object num:%d" %(_unreachable)
    print "garbage object num:%d" %(len(gc.garbage))   #gc.garbage是一个list对象，列表项是垃圾收集器发现的不可达（即垃圾对象）、但又不能释放(不可回收)的对象，通常gc.garbage中的对象是引用对象还中的对象。因Python不知用什么顺序来调用对象的__del__函数，导致对象始终存活在gc.garbage中，造成内存泄露 if __name__ == "__main__": test_gcleak()。如果知道一个安全次序，那么就可以打破引用焕，再执行del gc.garbage[:]从而清空垃圾对象列表

结果

begin leak test...
_gcleak ref count0: 2         #对象_gcleak的引用计数为2
_gcleak is invalid!           #因为执行了del函数，_gcleak变为了不可达的对象

begin collect...              #开始垃圾回收
unreachable object num:0      #本次垃圾回收发现的不可达的对象个数为0
garbage object num:0          #整个解释器中垃圾对象的个数为0

结论是对象_gcleak的引用计数是正确的，也没发生内存泄漏。

例2：对自己的循环引用造成内存泄露

import gc
import sys

class CGcLeak(object):
    def __init__(self):
        self._text = ‘#‘ * 10

    def __del__(self):
        pass

def make_circle_ref():
    _gcleak = CGcLeak()
    _gcleak._self = _gcleak     #自己循环引用自己
    print "_gcleak ref count0: %d" %(sys.getrefcount(_gcleak))
    del _gcleak
    try:
        print "_gcleak ref count1 :%d" %(sys.getrefcount(_gcleak))
    except UnboundLocalError:
        print "_gcleak is invalid!"

def test_gcleak():
    gc.enable()
    gc.set_debug(gc.DEBUG_COLLECTABLE | gc.DEBUG_UNCOLLECTABLE | gc.DEBUG_INSTANCES | gc.DEBUG_OBJECTS)

    print "begin leak test..."
    make_circle_ref()

    print "\nbegin collect..."
    _unreachable = gc.collect()
    print "unreachable object num:%d" %(_unreachable)
    print "garbage object num:%d" %(len(gc.garbage))

if __name__ == "__main__":
    test_gcleak()

结果

begin leak test...
gc: uncollectable <CGcLeak 00000000026366A0>
_gcleak ref count0: 3
_gcleak is invalid!
gc: uncollectable <dict 0000000002667BD8>

begin collect...
unreachable object num:2       #本次回收不可达的对象个数为2
garbage object num:1           #整个解释器中垃圾个数为1

例3：多个对象间的循环引用造成内存泄露　

import gc
import sys

class CGcLeakA(object):
    def __init__(self):
        self._text = ‘$‘ * 10

    def __del__(self):
        pass

class CGcLeakB(object):
    def __init__(self):
        self._text = ‘$‘ * 10

    def __del__(self):
        pass

def make_circle_ref():
    _a = CGcLeakA()
    _b = CGcLeakB()
    _a.s = _b
    _b.d = _a
    print "ref count0:a=%d b=%d" %(sys.getrefcount(_a), sys.getrefcount(_b))
    del _a
    del _b
    try:
        print "ref count1:a%d" %(sys.getrefcount(_a))
    except UnboundLocalError:
        print "_a is invalid!"

def test_gcleak():
    gc.enable()
    gc.set_debug(gc.DEBUG_COLLECTABLE | gc.DEBUG_UNCOLLECTABLE | gc.DEBUG_INSTANCES | gc.DEBUG_OBJECTS)

    print "begin leak test..."
    make_circle_ref()

    print "\nbegin collect..."
    _unreachable = gc.collect()
    print "unreachable object num:%d" %(_unreachable)
    print "garbage object num:%d" %(len(gc.garbage))

if __name__ == "__main__":
    test_gcleak()

结果

begin leak test...
ref count0:a=3 b=3
_a is invalid!

begin collect...
unreachable object num:4
garbage object num:2
gc: uncollectable <CGcLeakA 00000000022766D8>
gc: uncollectable <CGcLeakB 0000000002276710>
gc: uncollectable <dict 00000000022A7E18>
gc: uncollectable <dict 00000000022DF3C8>

结论

Python 的 gc 有比较强的功能，比如设置 gc.set_debug(gc.DEBUG_LEAK) 就可以进行循环引用导致的内存泄露的检查。如果在开发时进行内存泄露检查；在发布时能够确保不会内存泄露，那么就可以延长 Python 的垃圾回收时间间隔、甚至主动关闭垃圾回收机制，从而提高运行效率。

有待于深入研究的知识：监控Python中的引用计数

参考：Python的内存泄漏及gc模块的使用分析

郑重声明：本站内容如果来自互联网及其他传播媒体，其版权均属原媒体及文章作者所有。转载目的在于传递更多信息及用于网络分享，并不代表本站赞同其观点和对其真实性负责，也不构成任何其他建议。

Python垃圾回收机制:gc模块