一般来说在 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 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() 中,设置垃圾回收器调试标志后,再用 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): 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 ----------------
这次测试后输出结果为:
#----------------------------------------- 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 对象都发生了内存泄漏。因为二者是循环引用,垃圾回收器不知道该如何回收,也就是不知道该首先调用那个对象的 __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:0 garbage object num:0 #-----------------------------------------
结论:Python 的 gc 有比较强的功能,比如设置 gc.set_debug(gc.DEBUG_LEAK) 就可以进行循环引用导致的内存泄露的检查。如果在开发时进行内存泄露检查;在发布时能够确保不会内存泄露,那么就可以延长 Python 的垃圾回收时间间隔、甚至主动关闭垃圾回收机制,从而提高运行效率。
问题内容: 我有一个长时间运行的脚本,如果让脚本运行足够长的时间,它将消耗系统上的所有内存。 在不详细介绍脚本的情况下,我有两个问题: 是否有可遵循的“最佳实践”,以防止泄漏发生? 有什么技术可以调试Python中的内存泄漏? 问题答案: 看看这篇文章:跟踪python内存泄漏 另外,请注意,垃圾收集模块实际上可以设置调试标志。看一下功能。此外,请查看Gnibbler的这段代码,以确定调用后已创建
本文向大家介绍粗略分析Python中的内存泄漏,包括了粗略分析Python中的内存泄漏的使用技巧和注意事项,需要的朋友参考一下 引子 之前一直盲目的认为 Python 不会存在内存泄露, 但是眼看着上线的项目随着运行时间的增长 而越来越大的内存占用, 我意识到我写的程序在发生内存泄露, 之前 debug 过 logging 模块导致的内存泄露. 目前看来, 还有别的地方引起的内存泄露. 经过一天的
我使用5.6.21-70.0进行性能测试。 当我跑步时 mysqlslp-a--并发=40--查询次数1000次--迭代=500次--引擎=innodb--debug-info-utest-p 做一些性能测试,ram增长超过最大内存使用量,永不释放 当完成mysqlslap时,内存显示使用78% 我有1G物理内存,不使用交换 KiB Mem:总共1016656个,使用953808个,免费62848
问题内容: 我有一个Python程序,它运行一系列实验,没有打算从一个测试存储到另一个测试的数据。我的代码包含一个我完全找不到的内存泄漏(我已经查看了内存泄漏的其他线程)。由于时间限制,我不得不放弃寻找泄漏的机会,但是如果我能够隔离每个实验,该程序可能会运行足够长的时间以产生所需的结果。 在单独的线程中运行每个测试是否有帮助? 还有其他隔离泄漏影响的方法吗? 具体情况详 我的代码分为两部分:实验运
问题内容: 我有一个在django中运行的小型多线程脚本,随着时间的流逝,它开始使用越来越多的内存。将其保留一整天会消耗大约6GB的RAM,我开始进行交换。 在http://www.lshift.net/blog/2008/11/14/tracing-python-memory- leaks 之后,我将其视为最常见的类型(仅使用800M内存): 这没有什么奇怪的。我现在应该怎么做才能帮助调试内存问
问题内容: 我有一个网页正在IE8和Firefox中泄漏内存;Windows Process Explorer中显示的内存使用量只是随着时间的推移而不断增长。 下面的页面请求“ unplanned.json” URL,它是一个永不改变的静态文件(尽管我确实将HTTP标头设置为确保Ajax请求始终通过)。当得到结果时,它将清除HTML表,遍历从服务器返回的json数组,并为数组中的每个条目动态地向H