ref:// https://www.cnblogs.com/kaituorensheng/p/4449457.html
在Python中,为了解决内存泄露问题,采用了对象引用计数,并基于引用计数实现自动垃圾回收。
由于Python 有了自动垃圾回收功能,就造成了不少初学者误认为不必再受内存泄漏的骚扰了。但如果仔细查看一下Python文档对 __del__() 函数的描述,就知道这种好日子里也是有阴云的。下面摘抄一点文档内容如下:
|
|
可见,有 __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()

结果
| 1 2 3 4 5 6 7 8 9 10 11 |
|
结论
Python 的 gc 有比较强的功能,比如设置 gc.set_debug(gc.DEBUG_LEAK) 就可以进行循环引用导致的内存泄露的检查。如果在开发时进行内存泄露检查;在发布时能够确保不会内存泄露,那么就可以延长 Python 的垃圾回收时间间隔、甚至主动关闭垃圾回收机制,从而提高运行效率。
有待于深入研究的知识:监控Python中的引用计数
本文通过三个实例探讨了Python中由对象间循环引用导致的内存泄漏问题,并介绍了如何利用Python的gc模块进行内存泄漏检测。
796

被折叠的 条评论
为什么被折叠?



