博客分类：
对于一个用 python 实现的，长期运行的后台服务进程来说，如果内存持续增长，那么很可能是有了“内存泄露”。
最近在我的项目中，就出现了内存持续增长的情况，goolge 了一下，发现
讲了一种诊断方式，并给出了实例。而我的案例与此文稍有不同，下面就结合我的案例，谈谈如何诊断内存泄露：
一、内存泄露的原因
对于 python 这种支持垃圾回收的语言来说，怎么还会有内存泄露？ 概括来说，有以下三种原因：
1、 所用到的用 C 语言开发的底层模块中出现了内存泄露。
2、 代码中用到了全局的 list、 dict 或其它容器，不停的往这些容器中插入对象，而忘记了在使用完之后进行删除回收
3、 代码中有“引用循环”， python 垃圾处理机制无法进行回收
二、 内存泄露的诊断思路
无论是哪种方式的内存泄露，最终表现的形式都是某些 python 对象在不停的增长；因此，首先是要找到这些异常的对象。
三、 内存泄露的诊断步骤
用到的工具： gc 模块和
模块
objgraph 是一个用于诊断内存问题的有用的工具
1、 在服务程序的循环逻辑中，选择出一个诊断点
2、 在诊断点，插入如下诊断语句
import objgraph
### 强制进行垃圾回收
gc.collect()
### 打印出对象数目最多的 50 个类型信息
objgraph.show_most_common_types(limit=50)
3、 检查统计信息，找到异常对象。
运行加入诊断语句的服务程序，并将打印到屏幕上的统计信息重定向到日志中。
运行一段时间后，就可以来分析日志，看看哪些对象在不停的增长。
以我的程序为例，我将日志记录到 log.txt 中，运行一段时间后，发现 tuple 和 list 类型的对象不停增长：
# grep "^list " log.txt
# grep "^tuple " log.txt
如果不停增长的对象，是一些非通用的类型（例如你自己实现的一个 class），那么问题就比较好定位，例如 中提到的案例。
而对 tuple 和 list 这类通用类型，要想知道对象到底是什么，泄露发生在哪里，还得想点办法。我采用了排查的方式。由于程序的模块化还不错，可以每次禁用一个模块，然后重新跑程序，重新检查日志，看看 tuple 和 list 是否仍然不停增长。这样，很快就能将故障定位到具体的模块中。
最后终于找到了原因，属于上面总结的第二种原因：
我的程序是一个多线程程序，多个线程作为生产者，一个线程作为消费者，通过将一个 tuple 对象送入异步队列进行通信。由于消费者的处理速度跟不上生产者的速度，又没有进行同步， 导致异步队列中的对象越来越多。
四、参考文档
1.
浏览 12673
浏览: 59928 次
来自: 北京
呵，这是我以前写的，重新整理了贴在这里的有什么问题，可以一起交 ...
好文章啊！不知道小弟有问题可以请教吗？
(window.slotbydup=window.slotbydup || []).push({
id: '4773203',
container: s,
size: '200,200',
display: 'inlay-fix'Python的内存泄漏及gc模块的使用
Python的内存泄漏及gc模块的使用
&&-- 6.11日错误修正版
Horin|贺勤
Blog: http://blog.csdn.net/horin153/
&&& 在 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 sys
class CGcLeak(object):
__init__(self):
self._text = '#'*10
__del__(self):
def make_circle_ref():
&&& _gcleak =
#&& _gcleak._self = _gcleak #
test_code_1
'_gcleak ref count0:%d' % sys.getrefcount(_gcleak)
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()
'unreachable object num:%d' % _unreachable
'garbage object num:%d' % len(gc.garbage)
if __name__ == '__main__':
test_gcleak()
#--------------- code end ----------------
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
gc: uncollectable &dict
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):
__init__(self):
self._text = '#'*10
__del__(self):
class CGcLeakB(object):
__init__(self):
self._text = '*'*10
__del__(self):
def make_circle_ref():
CGcLeakA()
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 =
test_code_4
&&& del _a
&&& del _b
print 'ref count1:a=%d' % sys.getrefcount(_a)
&&& except
UnboundLocalError:
print '_a is invalid!'
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
gc: uncollectable &CGcLeakB
gc: uncollectable &dict
gc: uncollectable &dict
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垃圾回收算法描述,http://wiki./moin/python_ref_circle_gc
2, Garbage Collection for
Python,/nas/python/gc/
-----------------------------------------------------------------------------------
已投稿到：
以上网友发言只代表其个人观点，不代表新浪网的观点或立场。频道本月排行
随机推荐文章
Copyright (C) 2006 - 2016 www.
All Rights Reservedpython程序写得不好会有内存泄漏吗_百度知道
色情、暴力
我们会通过消息、邮箱等方式尽快将举报结果通知您。
python程序写得不好会有内存泄漏吗
我有更好的答案
C++写的模块（包），如果处理不好python本身不会造成内存泄露，可能会造成内存泄露，如果用的C&#47，但是也是C&#47
为您推荐：
其他类似问题
您可能关注的内容
换一换
回答问题，赢新手礼包