Python的內(nèi)存泄漏及gc模塊的使用分析
一般來說在 Python 中,為了解決內(nèi)存泄漏問題,采用了對象引用計數(shù),并基于引用計數(shù)實現(xiàn)自動垃圾回收。
由于Python 有了自動垃圾回收功能,就造成了不少初學者誤認為自己從此過上了好日子,不必再受內(nèi)存泄漏的騷擾了。但如果仔細查看一下Python文檔對 __del__() 函數(shù)的描述,就知道這種好日子里也是有陰云的。下面摘抄一點文檔內(nèi)容如下:
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__() 函數(shù)的對象間的循環(huán)引用是導致內(nèi)存泄漏的主兇。
另外需要說明:對沒有 __del__() 函數(shù)的 Python 對象間的循環(huán)引用,是可以被自動垃圾回收掉的。
如何知道一個對象是否內(nèi)存泄漏了呢?
方法一、當你認為一個對象應(yīng)該被銷毀時(即引用計數(shù)為 0),可以通過 sys.getrefcount(obj) 來獲取對象的引用計數(shù),并根據(jù)返回值是否為 0 來判斷是否內(nèi)存泄漏。如果返回的引用計數(shù)不為 0,說明在此刻對象 obj 是不能被垃圾回收器回收掉的。
方法二、也可以通過 Python 擴展模塊 gc 來查看不能回收的對象的詳細信息。
首先,來看一段正常的測試代碼:
#--------------- code begin -------------- # -*- coding: utf-8 -*- 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 # 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() 中,設(shè)置垃圾回收器調(diào)試標志后,再用 collect() 進行垃圾回收,最后打印出該次垃圾回收發(fā)現(xiàn)的不可達的垃圾對象數(shù)和整個解釋器中的垃圾對象數(shù)。
gc.garbage 是一個 list 對象,列表項是垃圾收集器發(fā)現(xiàn)的不可達(即是垃圾對象)、但又不能釋放(即不能回收)的對象。文檔描述為:A list of objects which the collector found to be unreachable but could not be freed (uncollectable objects).
通常,gc.garbage 中的對象是引用環(huán)中的對象。因為 Python 不知道按照什么樣的安全次序來調(diào)用環(huán)中對象的 __del__() 函數(shù),導致對象始終存活在 gc.garbage 中,造成內(nèi)存泄漏。如果知道一個安全的次序,那么就打破引用環(huán),再執(zhí)行 del gc.garbage[:] ,以清空垃圾對象列表。
上段代碼輸出為(#后字符串為筆者所加注釋):
#----------------------------------------- begin leak test... # 變量 _gcleak 的引用計數(shù)為 2. _gcleak ref count0:2 # _gcleak 變?yōu)椴豢蛇_(unreachable)的非法變量. _gcleak is invalid! # 開始垃圾回收 begin collect... # 本次垃圾回收發(fā)現(xiàn)的不可達的垃圾對象數(shù)為 0. unreachable object num:0 # 整個解釋器中的垃圾對象數(shù)為 0. garbage object num:0 #-----------------------------------------
由此可見 _gcleak 對象的引用計數(shù)是正確的,也沒有任何對象發(fā)生內(nèi)存泄漏。
如果不注釋掉 make_circle_ref() 中的 test_code_1 語句:
_gcleak._self = _gcleak
也就是讓 _gcleak 形成一個自己對自己的循環(huán)引用。再運行上述代碼,輸出結(jié)果就變成:
#----------------------------------------- begin leak test... _gcleak ref count0:3 _gcleak is invalid! begin collect... # 發(fā)現(xiàn)可以回收的垃圾對象: 地址為 012AA090,類型為 CGcLeak. gc: uncollectable <CGcLeak 012AA090> gc: uncollectable <dict 012AC1E0> unreachable object num:2 #!! 不能回收的垃圾對象數(shù)為 1,導致內(nèi)存泄漏! garbage object num:1 #-----------------------------------------
可見 <CGcLeak 012AA090> 對象發(fā)生了內(nèi)存泄漏??!而多出的 dict 垃圾就是泄漏的 _gcleak 對象的字典,打印出字典信息為:
{'_self': <__main__.CGcLeak object at 0x012AA090>, '_text': '##########'}
除了對自己的循環(huán)引用,多個對象間的循環(huán)引用也會導致內(nèi)存泄漏。簡單舉例如下:
#--------------- code begin -------------- 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._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 ----------------
這次測試后輸出結(jié)果為:
#----------------------------------------- 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:4 garbage object num:2 #-----------------------------------------
可見 _a,_b 對象都發(fā)生了內(nèi)存泄漏。因為二者是循環(huán)引用,垃圾回收器不知道該如何回收,也就是不知道該首先調(diào)用那個對象的 __del__() 函數(shù)。
采用以下任一方法,打破環(huán)狀引用,就可以避免內(nèi)存泄漏:
1.注釋掉 make_circle_ref() 中的 test_code_2 語句;
2.注釋掉 make_circle_ref() 中的 test_code_3 語句;
3.取消對 make_circle_ref() 中的 test_code_4 語句的注釋。
相應(yīng)輸出結(jié)果變?yōu)椋?/p>
#----------------------------------------- begin leak test... ref count0:a=2 b=3 # 注:此處輸出結(jié)果視情況變化. _a is invalid! _b is invalid! begin collect... unreachable object num:0 garbage object num:0 #-----------------------------------------
結(jié)論:Python 的 gc 有比較強的功能,比如設(shè)置 gc.set_debug(gc.DEBUG_LEAK) 就可以進行循環(huán)引用導致的內(nèi)存泄露的檢查。如果在開發(fā)時進行內(nèi)存泄露檢查;在發(fā)布時能夠確保不會內(nèi)存泄露,那么就可以延長 Python 的垃圾回收時間間隔、甚至主動關(guān)閉垃圾回收機制,從而提高運行效率。
相關(guān)文章
基于Tensorflow讀取MNIST數(shù)據(jù)集時網(wǎng)絡(luò)超時的解決方式
這篇文章主要介紹了基于Tensorflow讀取MNIST數(shù)據(jù)集時網(wǎng)絡(luò)超時的解決方式,具有很好的參考價值,希望對大家有所幫助。一起跟隨小編過來看看吧2020-06-06Python+Appium實現(xiàn)自動化清理微信僵尸好友的方法
這篇文章主要介紹了Python+Appium實現(xiàn)自動化清理微信僵尸好友的方法,文中通過示例代碼介紹的非常詳細,對大家的學習或者工作具有一定的參考學習價值,需要的朋友們下面隨著小編來一起學習學習吧2021-02-02python 下劃線的多種應(yīng)用場景總結(jié)
Python有很多地方使用下劃線,在不同場合下,有不同含義。本文總結(jié)Python語言編程中常用下劃線的地方,力圖一次搞懂下劃線的常見用法,感興趣的朋友快來一起看看吧2021-05-05Python中用post、get方式提交數(shù)據(jù)的方法示例
最近在學習使用Python,發(fā)現(xiàn)網(wǎng)上很少提到如何使用post,所以下面這篇文章主要給大家介紹了關(guān)于Python中用post、get方式提交數(shù)據(jù)的方法,文中通過示例代碼介紹的非常詳細,對大家的學習或者工作具有一定的參考學習價值,需要的朋友們下面來一起看看吧。2017-09-09