Python的内存泄漏及gc模块的使用分析
一般来说在Python中，为了解决内存泄漏问题，采用了对象引用计数，并基于引用计数实现自动垃圾回收。
由于Python有了自动垃圾回收功能，就造成了不少初学者误认为自己从此过上了好日子，不必再受内存泄漏的骚扰了。但如果仔细查看一下Python文档对__del__()函数的描述，就知道这种好日子里也是有阴云的。下面摘抄一点文档内容如下：
Somecommonsituationsthatmaypreventthereferencecountofanobjectfromgoingtozeroinclude:circularreferencesbetweenobjects(e.g.,adoubly-linkedlistoratreedatastructurewithparentandchildpointers);areferencetotheobjectonthestackframeofafunctionthatcaughtanexception(thetracebackstoredinsys.exc_tracebackkeepsthestackframealive);orareferencetotheobjectonthestackframethatraisedanunhandledexceptionininteractivemode(thetracebackstoredinsys.last_tracebackkeepsthestackframealive).
可见，有__del__()函数的对象间的循环引用是导致内存泄漏的主凶。
另外需要说明：对没有__del__()函数的Python对象间的循环引用，是可以被自动垃圾回收掉的。
如何知道一个对象是否内存泄漏了呢？
方法一、当你认为一个对象应该被销毁时（即引用计数为0），可以通过sys.getrefcount(obj)来获取对象的引用计数，并根据返回值是否为0来判断是否内存泄漏。如果返回的引用计数不为0，说明在此刻对象obj是不能被垃圾回收器回收掉的。
方法二、也可以通过Python扩展模块gc来查看不能回收的对象的详细信息。
首先，来看一段正常的测试代码：
#---------------codebegin-------------- #-*-coding:utf-8-*- importgc importsys classCGcLeak(object): def__init__(self): self._text='#'*10 def__del__(self): pass defmake_circle_ref(): _gcleak=CGcLeak() #_gcleak._self=_gcleak#test_code_1 print'_gcleakrefcount0:%d'%sys.getrefcount(_gcleak) del_gcleak try: print'_gcleakrefcount1:%d'%sys.getrefcount(_gcleak) exceptUnboundLocalError: print'_gcleakisinvalid!' deftest_gcleak(): #Enableautomaticgarbagecollection. gc.enable() #Setthegarbagecollectiondebuggingflags. gc.set_debug(gc.DEBUG_COLLECTABLE|gc.DEBUG_UNCOLLECTABLE|/ gc.DEBUG_INSTANCES|gc.DEBUG_OBJECTS) print'beginleaktest...' make_circle_ref() print'begincollect...' _unreachable=gc.collect() print'unreachableobjectnum:%d'%_unreachable print'garbageobjectnum:%d'%len(gc.garbage) if__name__=='__main__': test_gcleak()
在test_gcleak()中，设置垃圾回收器调试标志后，再用collect()进行垃圾回收，最后打印出该次垃圾回收发现的不可达的垃圾对象数和整个解释器中的垃圾对象数。
gc.garbage是一个list对象，列表项是垃圾收集器发现的不可达（即是垃圾对象）、但又不能释放（即不能回收）的对象。文档描述为：Alistofobjectswhichthecollectorfoundtobeunreachablebutcouldnotbefreed(uncollectableobjects).
通常，gc.garbage中的对象是引用环中的对象。因为Python不知道按照什么样的安全次序来调用环中对象的__del__()函数，导致对象始终存活在gc.garbage中，造成内存泄漏。如果知道一个安全的次序，那么就打破引用环，再执行delgc.garbage[:]，以清空垃圾对象列表。
上段代码输出为（#后字符串为笔者所加注释）：
#----------------------------------------- beginleaktest... #变量_gcleak的引用计数为2. _gcleakrefcount0:2 #_gcleak变为不可达(unreachable)的非法变量. _gcleakisinvalid! #开始垃圾回收 begincollect... #本次垃圾回收发现的不可达的垃圾对象数为0. unreachableobjectnum:0 #整个解释器中的垃圾对象数为0. garbageobjectnum:0 #-----------------------------------------
由此可见_gcleak对象的引用计数是正确的，也没有任何对象发生内存泄漏。
如果不注释掉make_circle_ref()中的test_code_1语句：
_gcleak._self=_gcleak
也就是让_gcleak形成一个自己对自己的循环引用。再运行上述代码，输出结果就变成：
#----------------------------------------- beginleaktest... _gcleakrefcount0:3 _gcleakisinvalid! begincollect... #发现可以回收的垃圾对象:地址为012AA090，类型为CGcLeak. gc:uncollectable<CGcLeak012AA090> gc:uncollectable<dict012AC1E0> unreachableobjectnum:2 #!!不能回收的垃圾对象数为1，导致内存泄漏！ garbageobjectnum:1 #-----------------------------------------
可见<CGcLeak012AA090>对象发生了内存泄漏！！而多出的dict垃圾就是泄漏的_gcleak对象的字典，打印出字典信息为:
{'_self':<__main__.CGcLeakobjectat0x012AA090>,'_text':'##########'}
除了对自己的循环引用，多个对象间的循环引用也会导致内存泄漏。简单举例如下：
#---------------codebegin-------------- classCGcLeakA(object): def__init__(self): self._text='#'*10 def__del__(self): pass classCGcLeakB(object): def__init__(self): self._text='*'*10 def__del__(self): pass defmake_circle_ref(): _a=CGcLeakA() _b=CGcLeakB() _a._b=_b#test_code_2 _b._a=_a#test_code_3 print'refcount0:a=%db=%d'%/ (sys.getrefcount(_a),sys.getrefcount(_b)) #_b._a=None#test_code_4 del_a del_b try: print'refcount1:a=%d'%sys.getrefcount(_a) exceptUnboundLocalError: print'_aisinvalid!' try: print'refcount2:b=%d'%sys.getrefcount(_b) exceptUnboundLocalError: print'_bisinvalid!' #---------------codeend----------------
这次测试后输出结果为：
#----------------------------------------- beginleaktest... refcount0:a=3b=3 _aisinvalid! _bisinvalid! begincollect... gc:uncollectable<CGcLeakA012AA110> gc:uncollectable<CGcLeakB012AA0B0> gc:uncollectable<dict012AC1E0> gc:uncollectable<dict012AC0C0> unreachableobjectnum:4 garbageobjectnum:2 #-----------------------------------------
可见_a,_b对象都发生了内存泄漏。因为二者是循环引用，垃圾回收器不知道该如何回收，也就是不知道该首先调用那个对象的__del__()函数。
采用以下任一方法，打破环状引用，就可以避免内存泄漏：
1.注释掉make_circle_ref()中的test_code_2语句；
2.注释掉make_circle_ref()中的test_code_3语句；
3.取消对make_circle_ref()中的test_code_4语句的注释。
相应输出结果变为：
#----------------------------------------- beginleaktest... refcount0:a=2b=3#注：此处输出结果视情况变化. _aisinvalid! _bisinvalid! begincollect... unreachableobjectnum:0 garbageobjectnum:0 #-----------------------------------------
结论：Python的gc有比较强的功能，比如设置gc.set_debug(gc.DEBUG_LEAK)就可以进行循环引用导致的内存泄露的检查。如果在开发时进行内存泄露检查；在发布时能够确保不会内存泄露，那么就可以延长Python的垃圾回收时间间隔、甚至主动关闭垃圾回收机制，从而提高运行效率。