[python]--垃圾回收機制

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

　　在python中,爲了解決內存泄漏的問題,採用了對象引用計數,並基於引用計數實現自動垃圾回收.

　　內存泄漏:也稱做"存儲滲漏".用動態 存儲分配函數動態開闢的空間,在使用完畢後未釋放,結果致使一直佔據該內存單元,直到程序結束.

　　內存泄漏形象的比喻是"操做系統可提供給全部進程的存儲空間正在被某個進程榨乾",最終結果是程序運行時間越長,佔用存儲空間愈來愈多,最終用盡所有存儲空間,整個系統崩潰.因此"內存泄漏"是從操做系統的角度來看的.這裏的存儲空間並非指物理內存,而是指虛擬內存大小,這個虛擬內存大小取決於磁盤交換區設定的大小,由程序申請的一塊內存,若是沒有任何一個指針指向它,那麼這塊內存就泄漏了.

　　內存泄漏分類:

　　　  常發性:

　　　　　　發生內存泄漏的代碼會被屢次執行到,每次被執行的時候都會致使一塊內存泄漏.

　　　　偶發性:

　　　　　　發生內存泄漏的代碼只有在某些特定環境或操做過程下才會發生.常發性和偶發性是相對的.對於特定的環境,偶發性的也許就變成常發性的.因此測試環境和測試方法對檢測內存泄漏相當重要.

　　　　一次性:

　　　　　　發生內存泄漏的代碼只會被執行一次,或者因爲算法上的缺陷,致使總會有一塊且僅一塊內存發生泄漏.好比,在類的構造函數中分配內存,在析構函數中卻沒有釋放該內存,因此內存泄漏只會發生一次.

　　　　隱式:

　　　　　　程序在運行過程當中不停的分配內存,可是直到結束的時候才釋放內存.嚴格的說這裏並無發生內存泄漏,由於最終程序釋放了全部申請的內存.可是對於一個服務器程序,須要運行幾天,幾周甚至幾個月,不及時釋放內存也可能致使最終耗盡系統的全部內存.因此,咱們稱這類內存泄漏爲隱式內存泄漏.

　　　　表現:

　　　　　　內存泄漏或者是說,資源耗盡後,系統會表現出什麼現象呢?

　　　　　　cpu資源耗盡:估計是機器沒有反應了,鍵盤,鼠標,以及網絡等等.在中了計算機病毒的設備上很是常見.

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

　　　　　　硬盤耗盡:機器要死了,交換內存無法用,日誌也無法用了.

　　　　　　內存泄漏或者內存耗盡:新的鏈接沒法建立,free的內存比較少,發生內存泄漏的程序不少,可是要想產生必定的後果,就須要這個進程是無限循環的,是個服務進程.固然,內核也是無限循環的,因此,若是內核發生了內存泄漏,狀況就更加不妙.內存泄漏是一種很難定位和跟蹤的錯誤,目前還沒看到有什麼好用的工具(固然,用戶空間有一些工具,有靜態分析的,也會動態分析的,可是找內核的內存泄漏,沒有好的開源工具).

　　　　　　　　　因爲Python有了自動垃圾回收功能,就形成了很多初學者誤認爲沒必要再受內存泄漏的騷擾了.但若是仔細查看一下Python文檔對__del__()函數的描述,就知道這種好日子裏也是有陰雲的.

　　　　有__del__()函數的對象間的循環引用是致使內存泄漏的主兇.但沒有__del__()函數的對象間的循環引用是能夠被垃圾回收器回收掉的.

　　　　Python的擴展模塊gc能夠查看不能回收掉的對象的詳細信息.

例子:沒有出現內存泄漏的　　　

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

結果

例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()

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       #本次回收不可達的對象個數爲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()

View Code

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 的垃圾回收時間間隔、甚至主動關閉垃圾回收機制，從而提升運行效率。