[python]--記憶體回收機制

標籤：display   初學   虛擬   不能   enable   電腦病毒   bsp   使用   垃圾收集器   

　　轉自http://www.cnblogs.com/kaituorensheng/p/4449457.html

　　在python中,為瞭解決記憶體流失的問題,採用了對象引用計數,並基於引用計數實現自動記憶體回收.

　　記憶體流失:也稱作"儲存滲漏".用動態 儲存分配函數動態開闢的空間,在使用完畢後未釋放,結果導致一直佔據該記憶體單元,直到程式結束.

　　記憶體流失形象的比喻是"作業系統可提供給所有進程的儲存空間正在被某個進程榨乾",最終結果是程式已耗用時間越長,佔用儲存空間越來越多,最終用盡全部儲存空間,整個系統崩潰.所以"記憶體流失"是從作業系統的角度來看的.這裡的儲存空間並不是指實體記憶體,而是指虛擬記憶體大小,這個虛擬記憶體大小取決於磁碟交換區設定的大小,由程式申請的一塊記憶體,如果沒有任何一個指標指向它,那麼這塊記憶體就泄漏了.

　　記憶體流失分類:

　　　  常發性:

　　　　　　發生記憶體流失的代碼會被多次執行到,每次被執行的時候都會導致一塊記憶體流失.

　　　　偶發性:

　　　　　　發生記憶體流失的代碼只有在某些特定環境或操作過程下才會發生.常發性和偶發性是相對的.對於特定的環境,偶發性的也許就變成常發性的.所以測試環境和測試方法對檢測記憶體流失至關重要.

　　　　一次性:

　　　　　　發生記憶體流失的代碼只會被執行一次,或者由於演算法上的缺陷,導致總會有一塊且僅一塊記憶體發生泄漏.比如,在類的建構函式中分配記憶體,在解構函式中卻沒有釋放該記憶體,所以記憶體流失只會發生一次.

　　　　隱式:

　　　　　　程式在運行過程中不停的分配記憶體,但是直到結束的時候才釋放記憶體.嚴格的說這裡並沒有發生記憶體流失,因為最終程式釋放了所有申請的記憶體.但是對於一個伺服器程式,需要運行幾天,幾周甚至幾個月,不及時釋放記憶體也可能導致最終耗盡系統的所有記憶體.所以,我們稱這類記憶體流失為隱式記憶體流失.

　　　　表現:

　　　　　　記憶體流失或者是說,資源耗盡後,系統會表現出什麼現象呢?

　　　　　　cpu資源耗盡:估計是機器沒有反應了,鍵盤,滑鼠,以及網路等等.在中了電腦病毒的裝置上非常常見.

　　　　　　進程id耗盡:沒法建立新的進程了,串口或者telnet都沒法建立了.

　　　　　　硬碟耗盡:機器要死了,交換記憶體沒法用,日誌也沒法用了.

　　　　　　記憶體流失或者記憶體耗盡:新的串連無法建立,free的記憶體比較少,發生記憶體流失的程式很多,但是要想產生一定的後果,就需要這個進程是無限迴圈的,是個服務進程.當然,核心也是無限迴圈的,所以,如果核心發生了記憶體流失,情況就更加不妙.記憶體流失是一種很難定位和跟蹤的錯誤,目前還沒看到有什麼好用的工具(當然,使用者空間有一些工具,有靜態分析的,也會動態分析的,但是找核心的記憶體流失,沒有好的開源工具).

　　　　　　　　　由於Python有了自動記憶體回收功能,就造成了不少初學者誤認為不必再受記憶體流失的騷擾了.但如果仔細查看一下Python文檔對__del__()函數的描述,就知道這種好日子裡也是有陰雲的.

　　　　有__del__()函數的對象間的循環參考是導致記憶體流失的主凶.但沒有__del__()函數的對象間的循環參考是可以被記憶體回收行程回收掉的.

　　　　Python的擴充模組gc可以查看不能回收掉的對象的詳細資料.

例子:沒有出現記憶體流失的　　　

import gc import sysclass CGcLeak(object):    def __init__(self):        self._text = ‘#‘ * 10    def __del__(self):        passdef 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      #本次記憶體回收發現的不可達的對象個數為0garbage object num:0          #整個解譯器中垃圾對象的個數為0

結果

例2：對自己的循環參考造成記憶體泄露

import gcimport sysclass CGcLeak(object):    def __init__(self):        self._text = ‘#‘ * 10    def __del__(self):        passdef 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()

View Code

begin leak test...gc: uncollectable <CGcLeak 00000000026366A0>_gcleak ref count0: 3_gcleak is invalid!gc: uncollectable <dict 0000000002667BD8>begin collect...unreachable object num:2       #本次回收不可達的對象個數為2garbage object num:1           #整個解譯器中垃圾個數為1

結果

例3：多個對象間的循環參考造成記憶體泄露

import gcimport sysclass 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.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()

View Code

begin leak test...ref count0:a=3 b=3_a is invalid! begin collect...unreachable object num:4garbage object num:2gc: 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]--記憶體回收機制