Python垃圾回收機制:gc模塊

    在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[:]從而清空垃圾對象列表
if __name__ == "__main__":
    test_gcleak()

 結果

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模塊的使用分析