Python的記憶體流失及gc模組的流量分析_python

一般來說在 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 對象間的循環參考，是可以被自動記憶體回收掉的。

如何知道一個對象是否記憶體流失了呢？

方法一、當你認為一個對象應該被銷毀時（即引用計數為 0），可以通過 sys.getrefcount(obj) 來擷取對象的引用計數，並根據傳回值是否為 0 來判斷是否記憶體流失。如果返回的引用計數不為 0，說明在此刻對象 obj 是不能被記憶體回收行程回收掉的。

方法二、也可以通過 Python 擴充模組 gc 來查看不能回收的對象的詳細資料。

首先，來看一段正常的測試代碼：

#--------------- code begin --------------# -*- coding: utf-8 -*-import gcimport sysclass CGcLeak(object):  def __init__(self):    self._text = '#'*10  def __del__(self):    passdef make_circle_ref():  _gcleak = CGcLeak()#  _gcleak._self = _gcleak # test_code_1  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():  # Enable automatic garbage collection.  gc.enable()  # Set the garbage collection debugging flags.  gc.set_debug(gc.DEBUG_COLLECTABLE | gc.DEBUG_UNCOLLECTABLE | /    gc.DEBUG_INSTANCES | gc.DEBUG_OBJECTS)  print 'begin leak test...'  make_circle_ref()  print 'begin collect...'  _unreachable = gc.collect()  print 'unreachable object num:%d' % _unreachable  print 'garbage object num:%d' % len(gc.garbage)if __name__ == '__main__':  test_gcleak()

在 test_gcleak() 中，設定記憶體回收行程調試標誌後，再用 collect() 進行記憶體回收，最後列印出該次記憶體回收發現的不可達的垃圾對象數和整個解譯器中的垃圾對象數。

gc.garbage 是一個 list 對象，清單項目是垃圾收集器發現的不可達（即是垃圾對象）、但又不能釋放（即不能回收）的對象。文檔描述為：A list of objects which the collector found to be unreachable but could not be freed (uncollectable objects).
通常，gc.garbage 中的對象是引用環中的對象。因為 Python 不知道按照什麼樣的安全次序來調用環中對象的 __del__() 函數，導致對象始終存活在 gc.garbage 中，造成記憶體流失。如果知道一個安全的次序，那麼就打破引用環，再執行 del gc.garbage[:] ，以清空垃圾對象列表。

上段代碼輸出為（#後字串為筆者所加註釋）：

#-----------------------------------------begin leak test...# 變數 _gcleak 的引用計數為 2._gcleak ref count0:2# _gcleak 變為不可達(unreachable)的非法變數._gcleak is invalid!# 開始記憶體回收begin collect...# 本次記憶體回收發現的不可達的垃圾對象數為 0.unreachable object num:0# 整個解譯器中的垃圾對象數為 0.garbage object num:0#-----------------------------------------

由此可見 _gcleak 對象的引用計數是正確的，也沒有任何對象發生記憶體流失。

如果不注釋掉 make_circle_ref() 中的 test_code_1 語句：

_gcleak._self = _gcleak

也就是讓 _gcleak 形成一個自己對自己的循環參考。再運行上述代碼，輸出結果就變成：

#-----------------------------------------begin leak test..._gcleak ref count0:3_gcleak is invalid!begin collect...# 發現可以回收的垃圾對象: 地址為 012AA090，類型為 CGcLeak.gc: uncollectable <CGcLeak 012AA090>gc: uncollectable <dict 012AC1E0>unreachable object num:2#!! 不能回收的垃圾對象數為 1，導致記憶體流失！garbage object num:1#-----------------------------------------

可見 <CGcLeak 012AA090> 對象發生了記憶體流失！！而多出的 dict 垃圾就是泄漏的 _gcleak 對象的字典，列印出字典資訊為:

{'_self': <__main__.CGcLeak object at 0x012AA090>, '_text': '##########'}

除了對自己的循環參考，多個對象間的循環參考也會導致記憶體流失。簡單舉例如下：

#--------------- code begin --------------class CGcLeakA(object):  def __init__(self):    self._text = '#'*10  def __del__(self):    passclass CGcLeakB(object):  def __init__(self):    self._text = '*'*10  def __del__(self):    passdef make_circle_ref():  _a = CGcLeakA()  _b = CGcLeakB()  _a._b = _b # test_code_2  _b._a = _a # test_code_3  print 'ref count0:a=%d b=%d' % /    (sys.getrefcount(_a), sys.getrefcount(_b))#  _b._a = None  # test_code_4  del _a  del _b  try:    print 'ref count1:a=%d' % sys.getrefcount(_a)  except UnboundLocalError:    print '_a is invalid!'  try:    print 'ref count2:b=%d' % sys.getrefcount(_b)  except UnboundLocalError:    print '_b is invalid!'#--------------- code end ----------------

這次測試後輸出結果為：

#-----------------------------------------begin leak test...ref count0:a=3 b=3_a is invalid!_b is invalid!begin collect...gc: uncollectable <CGcLeakA 012AA110>gc: uncollectable <CGcLeakB 012AA0B0>gc: uncollectable <dict 012AC1E0>gc: uncollectable <dict 012AC0C0>unreachable object num:4garbage object num: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 語句的注釋。

相應輸出結果變為：

#-----------------------------------------begin leak test...ref count0:a=2 b=3 # 註：此處輸出結果視情況變化._a is invalid!_b is invalid!begin collect...unreachable object num:0garbage object num:0#-----------------------------------------

結論：Python 的 gc 有比較強的功能，比如設定 gc.set_debug(gc.DEBUG_LEAK) 就可以進行循環參考導致的記憶體泄露的檢查。如果在開發時進行記憶體泄露檢查；在發布時能夠確保不會記憶體泄露，那麼就可以延長 Python 的記憶體回收時間間隔、甚至主動關閉記憶體回收機制，從而提高運行效率。