使用gc、objgraph干掉python内存泄露与循环引用！
正文
Python 使用引用计数和垃圾回收来做内存管理，前面也写过一遍文章《Python 内存优化》，介绍了在 python 中，如何 profile 内存使用情况，并做出相应的优化。本文介绍两个更致命的问题：内存泄露与循环引用。内存泄露是让所有程序员都闻风丧胆的问题，轻则导致程序运行速度减慢，重则导致程序崩溃；而循环引用是使用了引用计数的数据结构、编程语言都需要解决的问题。本文揭晓这两个问题在 python 语言中是如何存在的，然后试图利用 gc 模块和 objgraph 来解决这两个问题。
注意：本文的目标是 Cpython，测试代码都是运行在 Python2.7。另外，本文不考虑 C 扩展造成的内存泄露，这是另一个复杂且头疼的问题。
本文地址：http://www.cnblogs.com/xybaby/p/7491656.html
一分钟版本
（1）python 使用引用计数和垃圾回收来释放（free）Python 对象
（2）引用计数的优点是原理简单、将消耗均摊到运行时；缺点是无法处理循环引用
（3）Python 垃圾回收用于处理循环引用，但是无法处理循环引用中的对象定义了 __del__ 的情况，而且每次回收会造成一定的卡顿
python 内存管理
Python 中，一切都是对象，又分为 mutable 和 immutable 对象。二者区分的标准在于是否可以原地修改，“原地“”可以理解为相同的地址。可以通过 id() 查看一个对象的“地址”，如果通过变量修改对象的值，但 id 没发生变化，那么就是 mutable，否则就是 immutable。比如：
>>> a = 5;id(a)
35170056>>> a = 6;id(a)35170044
>>> lst = [1,2,3]; id(lst)39117168>>> lst.append(4); id(lst)39117168
a 指向的对象（int 类型）就是 immutable， 赋值语句只是让变量 a 指向了一个新的对象，因为 id 发生了变化。而 lst 指向的对象（list 类型）为可变对象，通过方法（append）可以修改对象的值，同时保证 id 一致。
判断两个变量是否相等（值相同）使用 ==， 而判断两个变量是否指向同一个对象使用 is。比如下面 a1 a2 这两个变量指向的都是空的列表，值相同，但是不是同一个对象。
>>> a1, a2 = [], []
>>> a1 == a2
True
>>> a1 is a2
False
为了避免频繁的申请、释放内存，避免大量使用的小对象的构造析构，python 有一套自己的内存管理机制。在巨著《Python 源码剖析》中有详细介绍，在 python 源码 obmalloc.h 中也有详细的描述。如下所示：
可以看到，python 会有自己的内存缓冲池（layer2）以及对象缓冲池（layer3）。在 Linux 上运行过 Python 服务器的程序都知道，python 不会立即将释放的内存归还给操作系统，这就是内存缓冲池的原因。而对于可能被经常使用、而且是immutable的对象，比如较小的整数、长度较短的字符串，python 会缓存在 layer3，避免频繁创建和销毁。例如：
>>> a, b = 1, 1
>>> a is b
True
>>> a, b = (), ()
>>> a is b
True
>>> a, b = {}, {}
>>> a is b
False
本文并不关心 python 是如何管理内存块、如何管理小对象，感兴趣的读者可以参考伯乐在线和csdn上的这两篇文章。
本文关心的是，一个普通的对象的生命周期，更明确的说，对象是什么时候被释放的。当一个对象理论上（或者逻辑上）不再被使用了，但事实上没有被释放，那么就存在内存泄露；当一个对象事实上已经不可达（unreachable），即不能通过任何变量找到这个对象，但这个对象没有立即被释放，那么则可能存在循环引用。
引用计数
引用计数（References count），指的是每个 Python 对象都有一个计数器，记录着当前有多少个变量指向这个对象。
将一个对象直接或者间接赋值给一个变量时，对象的计数器会加 1；当变量被 del 删除，或者离开变量所在作用域时，对象的引用计数器会减 1。当计数器归零的时候，代表这个对象再也没有地方可能使用了，因此可以将对象安全的销毁。Python 源码中，通过 Py_INCREF 和 Py_DECREF 两个宏来管理对象的引用计数，代码在 object.h
1 #define Py_INCREF(op) ( \ 2 _Py_INC_REFTOTAL _Py_REF_DEBUG_COMMA \ 3 ((PyObject*)(op))->ob_refcnt++) 4 5 #define Py_DECREF(op) \ 6 do { \ 7 if (_Py_DEC_REFTOTAL _Py_REF_DEBUG_COMMA \ 8 --((PyObject*)(op))->ob_refcnt != 0) \ 9 _Py_CHECK_REFCNT(op) \ 10 else \ 11 _Py_Dealloc((PyObject *)(op)); \ 12 } while (0)
通过 sys.getrefcount(obj) 对象可以获得一个对象的引用数目，返回值是真实引用数目加 1（加 1 的原因是 obj 被当做参数传入了 getrefcount 函数），例如：
>>> import sys
>>> s = 'asdf'
>>> sys.getrefcount(s)
2
>>> a = 1
>>> sys.getrefcount(a)
605
从对象 1 的引用计数信息也可以看到，python 的对象缓冲池会缓存十分常用的 immutable 对象，比如这里的整数 1。
引用计数的优点在于原理通俗易懂；且将对象的回收分布在代码运行时：一旦对象不再被引用，就会被释放掉（be freed），不会造成卡顿。但也有缺点：额外的字段（ob_refcnt）；频繁的加减 ob_refcnt，而且可能造成连锁反应。但这些缺点跟循环引用比起来都不算事儿。
什么是循环引用，就是一个对象直接或者间接引用自己本身，引用链形成一个环。且看下面的例子：
1 # -*- coding: utf-8 -*- 2 import objgraph, sys 3 class OBJ(object): 4 pass 5 6 def show_direct_cycle_reference(): 7 a = OBJ() 8 a.attr = a 9 objgraph.show_backrefs(a, max_depth=5, filename = "direct.dot") 10 11 def show_indirect_cycle_reference(): 12 a, b = OBJ(), OBJ() 13 a.attr_b = b 14 b.attr_a = a 15 objgraph.show_backrefs(a, max_depth=5, filename = "indirect.dot") 16 17 if __name__ == '__main__': 18 if len(sys.argv) > 1: 19 show_direct_cycle_reference() 20 else: 21 show_indirect_cycle_reference()
运行上面的代码，使用graphviz工具集（本文使用的是 dotty）打开生成的两个文件，direct.dot 和 indirect.dot，得到下面两个图
通过属性名 (attr, attr_a, attr_b）可以很清晰的看出循环引用是怎么产生的
前面已经提到，对于一个对象，当没有任何变量指向自己时，引用计数降到 0，就会被释放掉。我们以上面左边那个图为例，可以看到，红框里面的 OBJ 对象想在有两个引用（两个入度），分别来自帧对象 frame（代码中，函数局部空间持有对 OBJ 实例的引用）、attr 变量。我们再改一下代码，在函数运行技术之后看看是否还有 OBJ 类的实例存在，引用关系是怎么样的：
1 # -*- coding: utf-8 -*- 2 import objgraph, sys 3 class OBJ(object): 4 pass 5 6 def direct_cycle_reference(): 7 a = OBJ() 8 a.attr = a 9 10 if __name__ == '__main__': 11 direct_cycle_reference() 12 objgraph.show_backrefs(objgraph.by_type('OBJ')[0], max_depth=5, filename = "direct.dot"
修改后的代码，OBJ 实例 (a) 存在于函数的 local 作用域。因此，当函数调用结束之后，来自帧对象 frame 的引用被解除。从图中可以看到，当前对象的计数器（入度）为 1，按照引用计数的原理，是不应该被释放的，但这个对象在函数调用结束之后就是事实上的垃圾，这个时候就需要另外的机制来处理这种情况了。
python 的世界，很容易就会出现循环引用，比如标准库 Collections 中 OrderedDict 的实现（已去掉无关注释）：
1 class OrderedDict(dict): 2 def __init__(self, *args, **kwds): 3 if len(args) > 1: 4 raise TypeError('expected at most 1 arguments, got %d' % len(args)) 5 try: 6 self.__root 7 except AttributeError: 8 self.__root = root = [] # sentinel node 9 root[:] = [root, root, None] 10 self.__map = {} 11 self.__update(*args, **kwds)
注意第 8、9 行，root 是一个列表，列表里面的元素之自己本身！
垃圾回收
这里强调一下，本文中的的垃圾回收是狭义的垃圾回收，是指当出现循环引用，引用计数无计可施的时候采取的垃圾清理算法。
在 python 中，使用标记 - 清除算法（mark-sweep）和分代（generational）算法来垃圾回收。在《Garbage Collection for Python》一文中有对标记回收算法，然后在《Python 内存管理机制及优化简析》一文中，有对前文的翻译，并且有分代回收的介绍。在这里，引用后面一篇文章：
在 Python 中, 所有能够引用其他对象的对象都被称为容器 (container). 因此只有容器之间才可能形成循环引用. Python 的垃圾回收机制利用了这个特点来寻找需要被释放的对象. 为了记录下所有的容器对象, Python 将每一个 容器都链到了一个双向链表中, 之所以使用双向链表是为了方便快速的在容器集合中插入和删除对象. 有了这个 维护了所有容器对象的双向链表以后, Python 在垃圾回收时使用如下步骤来寻找需要释放的对象:
- 对于每一个容器对象, 设置一个
gc_refs值, 并将其初始化为该对象的引用计数值.- 对于每一个容器对象, 找到所有其引用的对象, 将被引用对象的
gc_refs值减 1.- 执行完步骤 2 以后所有
gc_refs值还大于 0 的对象都被非容器对象引用着, 至少存在一个非循环引用. 因此 不能释放这些对象, 将他们放入另一个集合.- 在步骤 3 中不能被释放的对象, 如果他们引用着某个对象, 被引用的对象也是不能被释放的, 因此将这些 对象也放入另一个集合中.
- 此时还剩下的对象都是无法到达的对象. 现在可以释放这些对象了.
关于分代回收：
除此之外, Python 还将所有对象根据’生存时间’分为 3 代, 从 0 到 2. 所有新创建的对象都分配为第 0 代. 当这些对象 经过一次垃圾回收仍然存在则会被放入第 1 代中. 如果第 1 代中的对象在一次垃圾回收之后仍然存货则被放入第 2 代. 对于不同代的对象 Python 的回收的频率也不一样. 可以通过
gc.set_threshold(threshold0[, threshold1[, threshold2]])来定义. 当 Python 的垃圾回收器中新增的对象数量减去删除的对象数量大于 threshold0 时, Python 会对第 0 代对象 执行一次垃圾回收. 每当第 0 代被检查的次数超过了 threshold1 时, 第 1 代对象就会被执行一次垃圾回收. 同理每当 第 1 代被检查的次数超过了 threshold2 时, 第 2 代对象也会被执行一次垃圾回收.
注意，threshold0，threshold1，threshold2 的意义并不相同！
为什么要分代呢，这个算法的根源来自于 weak generational hypothesis。这个假说由两个观点构成：首先是年亲的对象通常死得也快，比如大量的对象都存在于 local 作用域；而老对象则很有可能存活更长的时间，比如全局对象，module， class。
垃圾回收的原理就如上面提示，详细的可以看 Python 源码，只不过事实上垃圾回收器还要考虑 __del__，弱引用等情况，会略微复杂一些。
什么时候会触发垃圾回收呢，有三种情况：
（1）达到了垃圾回收的阈值，Python 虚拟机自动执行
（2）手动调用 gc.collect()
（3）Python 虚拟机退出的时候
对于垃圾回收，有两个非常重要的术语，那就是reachable 与 collectable（当然还有与之对应的 unreachable 与 uncollectable），后文也会大量提及。
reachable 是针对 python 对象而言，如果从根集（root）能到找到对象，那么这个对象就是 reachable，与之相反就是 unreachable，事实上就是只存在于循环引用中的对象，Python 的垃圾回收就是针对 unreachable 对象。
而 collectable 是针对 unreachable 对象而言，如果这种对象能被回收，那么是 collectable；如果不能被回收，即循环引用中的对象定义了 __del__， 那么就是 uncollectable。Python 垃圾回收对 uncollectable 对象无能为力，会造成事实上的内存泄露。
gc module
这里的 gc（garbage collector）是 Python 标准库，该 module 提供了与上一节“垃圾回收”内容相对应的接口。通过这个 module，可以开关 gc、调整垃圾回收的频率、输出调试信息。gc 模块是很多其他模块（比如 objgraph）封装的基础，在这里先介绍 gc 的核心 API。
gc.enable(); gc.disable(); gc.isenabled()
开启 gc（默认情况下是开启的）；关闭 gc；判断 gc 是否开启
gc.collection()
执行一次垃圾回收，不管 gc 是否处于开启状态都能使用
gc.set_threshold(t0, t1, t2); gc.get_threshold()
设置垃圾回收阈值； 获得当前的垃圾回收阈值
注意：gc.set_threshold(0) 也有禁用 gc 的效果
gc.get_objects()
返回所有被垃圾回收器（collector）管理的对象。这个函数非常基础！只要 python 解释器运行起来，就有大量的对象被 collector 管理，因此，该函数的调用比较耗时！
比如，命令行启动 python
>>> import gc
>>> len(gc.get_objects())
3749
gc.get_referents(*obj)
返回 obj 对象直接指向的对象
gc.get_referrers(*obj)
返回所有直接指向 obj 的对象
下面的实例展示了 get_referents 与 get_referrers 两个函数
>>> class OBJ(object):
... pass
...
>>> a, b = OBJ(), OBJ()
>>> hex(id(a)), hex(id(b))
('0x250e730','0x250e7f0')
>>> gc.get_referents(a)
[<class '__main__.OBJ'>]
>>> a.attr = b
>>> gc.get_referents(a)
[{'attr': <__main__.OBJ object at 0x0250E7F0>}, <class '__main__.OBJ'>]
>>> gc.get_referrers(b)
[{'attr': <__main__.OBJ object at 0x0250E7F0>}, {'a': <__main__.OBJ object at 0x0250E730>, 'b': <__main__.OBJ object at 0x0250E7F0>, 'OBJ': <class '__main__.OBJ'>, '__builtins__': <modu
le '__builtin__' (built-in)>, '__package__': None, 'gc': <module 'gc' (built-in)>, '__name__': '__main__', '__doc__': None}]
>>>
a, b 都是类 OBJ 的实例，执行 "a.attr = b" 之后，a 就通过‘’attr“这个属性指向了 b。
gc.set_debug(flags)
设置调试选项，非常有用，常用的 flag 组合包含以下
gc.DEBUG_COLLETABLE： 打印可以被垃圾回收器回收的对象
gc.DEBUG_UNCOLLETABLE： 打印无法被垃圾回收器回收的对象，即定义了 __del__ 的对象
gc.DEBUG_SAVEALL：当设置了这个选项，可以被拉起回收的对象不会被真正销毁（free），而是放到 gc.garbage 这个列表里面，利于在线上查找问题
内存泄露
既然 Python 中通过引用计数和垃圾回收来管理内存，那么什么情况下还会产生内存泄露呢？有两种情况：
第一是对象被另一个生命周期特别长的对象所引用，比如网络服务器，可能存在一个全局的单例 ConnectionManager，管理所有的连接 Connection，如果当 Connection 理论上不再被使用的时候，没有从 ConnectionManager 中删除，那么就造成了内存泄露。
第二是循环引用中的对象定义了 __del__ 函数，这个在《程序员必知的 Python 陷阱与缺陷列表》一文中有详细介绍，简而言之，如果定义了 __del__ 函数，那么在循环引用中 Python 解释器无法判断析构对象的顺序，因此就不错处理。
在任何环境，不管是服务器，客户端，内存泄露都是非常严重的事情。
如果是线上服务器，那么一定得有监控，如果发现内存使用率超过设置的阈值则立即报警，尽早发现些许还有救。当然，谁也不希望在线上修复内存泄露，这无疑是给行驶的汽车换轮子，因此尽量在开发环境或者压力测试环境发现并解决潜在的内存泄露。在这里，发现问题最为关键，只要发现了问题，解决问题就非常容易了，因为按照前面的说法，出现内存泄露只有两种情况，在第一种情况下，只要在适当的时机解除引用就可以了；在第二种情况下，要么不再使用 __del__ 函数，换一种实现方式，要么解决循环引用。
那么怎么查找哪里存在内存泄露呢？武器就是两个库：gc、objgraph
在上面已经介绍了 gc 这个模块，理论上，通过 gc 模块能够拿到所有的被 garbage collector 管理的对象，也能知道对象之间的引用和被引用关系，就可以画出对象之间完整的引用关系图。但事实上还是比较复杂的，因为在这个过程中一不小心又会引入新的引用关系，所以，有好的轮子就直接用吧，那就是objgraph。
objgraph
objgraph 的实现调用了 gc 的这几个函数：gc.get_objects(), gc.get_referents(), gc.get_referers()，然后构造出对象之间的引用关系。objgraph 的代码和文档都写得比较好，建议一读。
下面先介绍几个十分实用的 API
def count(typename)
返回该类型对象的数目，其实就是通过 gc.get_objects() 拿到所用的对象，然后统计指定类型的数目。
def by_type(typename)
返回该类型的对象列表。线上项目，可以用这个函数很方便找到一个单例对象
def show_most_common_types(limits = 10)
打印实例最多的前 N（limits）个对象，这个函数非常有用。在《Python 内存优化》一文中也提到，该函数能发现可以用 slots 进行内存优化的对象
def show_growth()
统计自上次调用以来增加得最多的对象，这个函数非常有利于发现潜在的内存泄露。函数内部调用了 gc.collect()，因此即使有循环引用也不会对判断造成影响。
值得一提，该函数的实现非常有意思，简化后的代码如下：
1 def show_growth(limit=10, peak_stats={}, shortnames=True, file=None): 2 gc.collect() 3 stats = typestats(shortnames=shortnames) 4 deltas = {} 5 for name, count in iteritems(stats): 6 old_count = peak_stats.get(name, 0) 7 if count > old_count: 8 deltas[name] = count - old_count 9 peak_stats[name] = count 10 deltas = sorted(deltas.items(), key=operator.itemgetter(1), 11 reverse=True)
注意形参 peak_stats 使用了可变参数作为默认形参，这样很方便记录上一次的运行结果。在《程序员必知的 Python 陷阱与缺陷列表》中提到，使用可变对象做默认形参是最为常见的 python 陷阱，但在这里，却成为了方便的利器！
def show_backrefs()
生产一张有关 objs 的引用图，看出看出对象为什么不释放，后面会利用这个 API 来查内存泄露。
该 API 有很多有用的参数，比如层数限制 (max_depth)、宽度限制 (too_many)、输出格式控制 (filename output)、节点过滤 (filter, extra_ignore)，建议使用之间看一些 document。
def find_backref_chain(obj, predicate, max_depth=20, extra_ignore=()):
找到一条指向 obj 对象的最短路径，且路径的头部节点需要满足 predicate 函数 （返回值为 True）
可以快捷、清晰指出 对象的被引用的情况，后面会展示这个函数的威力
def show_chain():
将 find_backref_chain 找到的路径画出来, 该函数事实上调用 show_backrefs，只是排除了所有不在路径中的节点。
查找内存泄露
在这一节，介绍如何利用 objgraph 来查找内存是怎么泄露的
如果我们怀疑一段代码、一个模块可能会导致内存泄露，那么首先调用一次 obj.show_growth()，然后调用相应的函数，最后再次调用 obj.show_growth()，看看是否有增加的对象。比如下面这个简单的例子：
1 # -*- coding: utf-8 -*- 2 import objgraph 3 4 _cache = [] 5 6 class OBJ(object): 7 pass 8 9 def func_to_leak(): 10 o = OBJ() 11 _cache.append(o) 12 # do something with o, then remove it from _cache 13 14 if True: # this seem ugly, but it always exists 15 return 16 _cache.remove(o) 17 18 if __name__ == '__main__': 19 objgraph.show_growth() 20 try: 21 func_to_leak() 22 except: 23 pass 24 print 'after call func_to_leak' 25 objgraph.show_growth()
运行结果（我们只关心后一次 show_growth 的结果）如下
wrapper_descriptor 1073 +13
member_descriptor 204 +5
getset_descriptor 168 +5
weakref 338 +3
dict 458 +3
OBJ 1 +1
代码很简单，函数开始的时候讲对象加入了 global 作用域的 _cache 列表，然后期望是在函数退出之前从 _cache 删除，但是由于提前返回或者异常，并没有执行到最后的 remove 语句。从运行结果可以发现，调用函数之后，增加了一个类 OBJ 的实例，然而理论上函数调用结束之后，所有在函数作用域（local）中声明的对象都改被销毁，因此这里就存在内存泄露。
当然，在实际的项目中，我们也不清楚泄露是在哪段代码、哪个模块中发生的，而且往往是发生了内存泄露之后再去排查，这个时候使用 obj.show_most_common_types 就比较合适了，如果一个自定义的类的实例数目特别多，那么就可能存在内存泄露。如果在压力测试环境，停止压测，调用 gc.collet，然后再用 obj.show_most_common_types 查看，如果对象的数目没有相应的减少，那么肯定就是存在泄露。
当我们定位了哪个对象发生了内存泄露，那么接下来就是分析怎么泄露的，引用链是怎么样的，这个时候就该 show_backrefs 出马了，还是以之前的代码为例，稍加修改：
1 import objgraph 2 3 _cache = [] 4 5 class OBJ(object): 6 pass 7 8 def func_to_leak(): 9 o = OBJ() 10 _cache.append(o) 11 # do something with o, then remove it from _cache 12 13 if True: # this seem ugly, but it always exists 14 return 15 _cache.remove(o) 16 17 if __name__ == '__main__': 18 try: 19 func_to_leak() 20 except: 21 pass 22 objgraph.show_backrefs(objgraph.by_type('OBJ')[0], max_depth = 10, filename = 'obj.dot')
注意，上面的代码中，max_depth 参数非常关键，如果这个参数太小，那么看不到完整的引用链，如果这个参数太大，运行的时候又非常耗时间。
然后打开 dot 文件，结果如下
可以看到泄露的对象（红框表示），是被一个叫 _cache 的 list 所引用，而 _cache 又是被 __main__ 这个 module 所引用。
对于示例代码，dot 文件的结果已经非常清晰，但是对于真实项目，引用链中的节点可能成百上千，看起来非常头大，下面用 tornado 起一个最最简单的 web 服务器（代码不知道来自哪里，且没有内存泄露，这里只是为了显示引用关系），然后绘制 socket 的引用关关系图，代码和引用关系图如下：
1 import objgraph 2 import errno 3 import functools 4 import tornado.ioloop 5 import socket 6 7 def connection_ready(sock, fd, events): 8 while True: 9 try: 10 connection, address = sock.accept() 11 print 'connection_ready', address 12 except socket.error as e: 13 if e.args[0] not in (errno.EWOULDBLOCK, errno.EAGAIN): 14 raise 15 return 16 connection.setblocking(0) 17 # do sth with connection 18 19 20 if __name__ == '__main__': 21 sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM, 0) 22 sock.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) 23 sock.setblocking(0) 24 sock.bind(("", 8888)) 25 sock.listen(128) 26 27 io_loop = tornado.ioloop.IOLoop.current() 28 callback = functools.partial(connection_ready, sock) 29 io_loop.add_handler(sock.fileno(), callback, io_loop.READ) 30 #objgraph.show_backrefs(sock, max_depth = 10, filename = 'tornado.dot') 31 # objgraph.show_chain( 32 # objgraph.find_backref_chain( 33 # sock, 34 # objgraph.is_proper_module 35 # ), 36 # filename='obj_chain.dot' 37 # ) 38 io_loop.start()
可见，代码越复杂，相互之间的引用关系越多，show_backrefs 越难以看懂。这个时候就使用 show_chain 和 find_backref_chain 吧，这种方法，在官方文档也是推荐的，我们稍微改改代码，结果如下：
1 import objgraph 2 3 _cache = [] 4 5 class OBJ(object): 6 pass 7 8 def func_to_leak(): 9 o = OBJ() 10 _cache.append(o) 11 # do something with o, then remove it from _cache 12 13 if True: # this seem ugly, but it always exists 14 return 15 _cache.remove(o) 16 17 if __name__ == '__main__': 18 try: 19 func_to_leak() 20 except: 21 pass 22 # objgraph.show_backrefs(objgraph.by_type('OBJ')[0], max_depth = 10, filename = 'obj.dot') 23 objgraph.show_chain( 24 objgraph.find_backref_chain( 25 objgraph.by_type('OBJ')[0], 26 objgraph.is_proper_module 27 ), 28 filename='obj_chain.dot' 29 )
上面介绍了内存泄露的第一种情况，对象被“非期望”地引用着。下面看看第二种情况，循环引用中的 __del__， 看下面的代码：
1 # -*- coding: utf-8 -*- 2 import objgraph, gc 3 class OBJ(object): 4 def __del__(self): 5 print('Dangerous!') 6 7 def show_leak_by_del(): 8 a, b = OBJ(), OBJ() 9 a.attr_b = b 10 b.attr_a = a 11 12 del a, b 13 print gc.collect() 14 15 objgraph.show_backrefs(objgraph.by_type('OBJ')[0], max_depth = 10, filename = 'del_obj.dot')
上面的代码存在循环引用，而且 OBJ 类定义了 __del__ 函数。如果没有定义 __del__ 函数，那么上述的代码会报错， 因为 gc.collect 会将循环引用删除，objgraph.by_type('OBJ') 返回空列表。而因为定义了 __del__ 函数，gc.collect 也无能为力，结果如下：
从图中可以看到，对于这种情况，还是比较好辨识的，因为 objgraph 将 __del__ 函数用特殊颜色标志出来，一眼就看见了。另外，可以看见 gc.garbage（类型是 list）也引用了这两个对象，原因在 document 中有描述，当执行垃圾回收的时候，会将定义了 __del__ 函数的类实例（被称为 uncollectable object）放到 gc.garbage 列表，因此，也可以直接通过查看 gc.garbage 来找出定义了 __del__ 的循环引用。在这里，通过增加 extra_ignore 来排除 gc.garbage 的影响：
将上述代码的最后一行改成：
objgraph.show_backrefs(objgraph.by_type('OBJ')[0], extra_ignore=(id(gc.garbage),), max_depth = 10, filename = 'del_obj.dot')
另外，也可以设置 DEBUG_UNCOLLECTABLE 选项，直接将 uncollectable 对象输出到标准输出，而不是放到 gc.garbage
循环引用
除非定义了 __del__ 方法，那么循环引用也不是什么万恶不赦的东西，因为垃圾回收器可以处理循环引用，而且不准是 python 标准库还是大量使用的第三方库，都可能存在循环引用。如果存在循环引用，那么 Python 的 gc 就必须开启（gc.isenabled() 返回 True），否则就会内存泄露。但是在某些情况下，我们还是不希望有 gc，比如对内存和性能比较敏感的应用场景，在这篇文章中，提到 instagram 通过禁用 gc，性能提升了 10%；另外，在一些应用场景，垃圾回收带来的卡顿也是不能接受的，比如 RPG 游戏。从前面对垃圾回收的描述可以看到，执行一次垃圾回收是很耗费时间的，因为需要遍历所有被 collector 管理的对象（即使很多对象不属于垃圾）。因此，要想禁用 GC，就得先彻底干掉循环引用。
同内存泄露一样，解除循环引用的前提是定位哪里出现了循环引用。而且，如果需要在线上应用关闭 gc，那么需要自动、持久化的进行检测。下面介绍如何定位循环引用，以及如何解决循环引用。
定位循环引用
这里还是是用 GC 模块和 objgraph 来定位循环引用。需要注意的事，一定要先禁用 gc（调用 gc.disable()）， 防止误差。
这里利用之前介绍循环引用时使用过的例子： a， b 两个 OBJ 对象形成循环引用
1 # -*- coding: utf-8 -*- 2 import objgraph, gc 3 class OBJ(object): 4 pass 5 6 def show_cycle_reference(): 7 a, b = OBJ(), OBJ() 8 a.attr_b = b 9 b.attr_a = a 10 11 if __name__ == '__main__': 12 gc.disable() 13 for _ in xrange(50): 14 show_cycle_reference() 15 objgraph.show_most_common_types(20)
运行结果（部分）：
wrapper_descriptor 1060
dict 555
OBJ 100
上面的代码中使用的是 show_most_common_types，而没有使用 show_growth（因为 growth 会手动调用 gc.collect()），通过结果可以看到，内存中现在有 100 个 OBJ 对象，符合预期。当然这些 OBJ 对象没有在函数调用后被销毁，不一定是循环引用的问题，也可能是内存泄露，比如前面 OBJ 对象被 global 作用域中的 _cache 引用的情况。怎么排除是否是被 global 作用域的变量引用的情况呢，方法还是 objgraph.find_backref_chain(obj)，在 __doc__ 中指出，如果找不到符合条件的应用链（chain），那么返回 [obj]，稍微修改上面的代码：
1 # -*- coding: utf-8 -*- 2 import objgraph, gc 3 class OBJ(object): 4 pass 5 6 def show_cycle_reference(): 7 a, b = OBJ(), OBJ() 8 a.attr_b = b 9 b.attr_a = a 10 11 if __name__ == '__main__': 12 gc.disable() 13 for _ in xrange(50): 14 show_cycle_reference() 15 ret = objgraph.find_backref_chain(objgraph.by_type('OBJ')[0], objgraph.is_proper_module) 16 print ret
上面的代码输出：
[<__main__.OBJ object at 0x0244F810>]
验证了我们的想法，OBJ 对象不是被 global 作用域的变量所引用。
在实际项目中，不大可能到处用 objgraph.show_most_common_types 或者 objgraph.by_type 来排查循环引用，效率太低。有没有更好的办法呢，有的，那就是使用 gc 模块的 debug 选项。在前面介绍 gc 模块的时候，就介绍了 gc.DEBUG_COLLECTABLE 选项，我们来试试：
1 # -*- coding: utf-8 -*- 2 import gc, time 3 class OBJ(object): 4 pass 5 6 def show_cycle_reference(): 7 a, b = OBJ(), OBJ() 8 a.attr_b = b 9 b.attr_a = a 10 11 if __name__ == '__main__': 12 gc.disable() # 这里是否 disable 事实上无所谓 13 gc.set_debug(gc.DEBUG_COLLECTABLE | gc.DEBUG_OBJECTS) 14 for _ in xrange(1): 15 show_cycle_reference() 16 gc.collect() 17 time.sleep(5)
上面代码第 13 行设置了 debug flag，可以打印出 collectable 对象。另外，只用调用一次 show_cycle_reference 函数就足够了（这也比 objgraph.show_most_common_types 方便一点）。在第 16 行手动调用 gc.collect()，输出如下：
gc: collectable <OBJ 023B46F0>
gc: collectable <OBJ 023B4710>
gc: collectable <dict 023B7AE0>
gc: collectable <dict 023B7930>
注意：只有当对象是 unreachable 且 collectable 的时候，在 collect 的时候才会被输出，也就是说，如果是 reachable，比如被 global 作用域的变量引用，那么也是不会输出的。
通过上面的输出，我们已经知道 OBJ 类的实例存在循环引用，但是这个时候，obj 实例已经被回收了。那么如果我想通过 show_backrefs 找出这个引用关系，需要重新调用 show_cycle_reference 函数，然后不调用 gc.collect，通过 show_backrefs 和 by_type 绘制。有没有更好的办法呢，可以让我在一次运行中发现循环引用，并找出引用链？答案就是使用 DEBUG_SAVEALL，下面为了展示方便，直接在命令行中操作（当然，使用 ipython 更好）
>>> import gc, objgraph
>>> class OBJ(object):
... pass
...
>>> def show_cycle_reference():
... a, b = OBJ(), OBJ()
... a.attr_b = b
... b.attr_a = a
...
>>> gc.set_debug(gc.DEBUG_SAVEALL| gc.DEBUG_OBJECTS)
>>> show_cycle_reference()
>>> print 'before collect', gc.garbage
before collect []
>>> print gc.collect()
4
>>>
>>> for o in gc.garbage:
... print o
...
<__main__.OBJ object at 0x024BB7D0>
<__main__.OBJ object at 0x02586850>
{'attr_b': <__main__.OBJ object at 0x02586850>}
{'attr_a': <__main__.OBJ object at 0x024BB7D0>}
>>>
>>> objgraph.show_backrefs(objgraph.at(0x024BB7D0), 5, filename = 'obj.dot')
Graph written to obj.dot (13 nodes)
>>>
上面在调用 gc.collect 之前，gc.garbage 里面是空的，由于设置了 DEBUG_SAVEALL，那么调用 gc.collect 时，会将 collectable 对象放到 gc.garbage。此时，对象没有被释放，我们就可以直接绘制出引用关系，这里使用了 objgraph.at，当然也可以使用 objgraph.by_type， 或者直接从 gc.garbage 取对象，结果如下：
出了循环引用，可以看见还有两个引用，gc.garbage 与局部变量 o，相信大家也能理解。
消灭循环引用
找到循环引用关系之后，解除循环引用就不是太难的事情，总的来说，有两种办法：手动解除与使用 weakref。
手动解除很好理解，就是在合适的时机，解除引用关系。比如，前面提到的 collections.OrderedDict：
>>> root = []
>>> root[:] = [root, root, None]
>>>
>>> root
[[...], [...], None]
>>>
>>> del root[:]
>>> root
[]
更常见的情况，是我们自定义的对象之间存在循环引用：要么是单个对象内的循环引用，要么是多个对象间的循环引用，我们看一个单个对象内循环引用的例子：
1 class Connection(object): 2 MSG_TYPE_CHAT = 0X01 3 MSG_TYPE_CONTROL = 0X02 4 def __init__(self): 5 self.msg_handlers = { 6 self.MSG_TYPE_CHAT : self.handle_chat_msg, 7 self.MSG_TYPE_CONTROL : self.handle_control_msg 8 } 9 10 def on_msg(self, msg_type, *args): 11 self.msg_handlers[msg_type](*args) 12 13 def handle_chat_msg(self, msg): 14 pass 15 16 def handle_control_msg(self, msg): 17 pass
上面的代码非常常见，代码也很简单，初始化函数中为每种消息类型定义响应的处理函数，当消息到达 (on_msg) 时根据消息类型取出处理函数。但这样的代码是存在循环引用的，感兴趣的读者可以用 objgraph 看看引用图。如何手动解决呢，为 Connection 增加一个 destroy（或者叫 clear）函数，该函数将 self.msg_handlers 清空（self.msg_handlers.clear()）。当 Connection 理论上不在被使用的时候调用 destroy 函数即可。
对于多个对象间的循环引用，处理方法也是一样的，就是在“适当的时机”调用 destroy 函数，难点在于什么是适当的时机。
另外一种更方便的方法，就是使用弱引用weakref， weakref 是 Python 提供的标准库，旨在解决循环引用。
weakref 模块提供了以下一些有用的 API：
（1）weakref.ref(object, callback = None)
创建一个对 object 的弱引用，返回值为 weakref 对象，callback: 当 object 被删除的时候，会调用 callback 函数，在标准库 logging （__init__.py）中有使用范例。使用的时候要用 () 解引用，如果 referant 已经被删除，那么返回 None。比如下面的例子
1 # -*- coding: utf-8 -*- 2 import weakref 3 class OBJ(object): 4 def f(self): 5 print 'HELLO' 6 7 if __name__ == '__main__': 8 o = OBJ() 9 w = weakref.ref(o) 10 w().f() 11 del o 12 w().f()
运行上面的代码，第 12 行会抛出异常：AttributeError: 'NoneType' object has no attribute 'f'。因为这个时候被引用的对象已经被删除了
（2）weakref.proxy(object, callback = None)
创建一个代理，返回值是一个 weakproxy 对象，callback 的作用同上。使用的时候直接用 和 object 一样，如果 object 已经被删除 那么跑出异常 ReferenceError: weakly-referenced object no longer exists。
1 # -*- coding: utf-8 -*- 2 import weakref 3 class OBJ(object): 4 def f(self): 5 print 'HELLO' 6 7 if __name__ == '__main__': 8 o = OBJ() 9 w = weakref.proxy(o) 10 w.f() 11 del o 12 w.f()
注意第 10 行 12 行与 weakref.ref 示例代码的区别
（3）weakref.WeakSet
这个是一个弱引用集合，当 WeakSet 中的元素被回收的时候，会自动从 WeakSet 中删除。WeakSet 的实现使用了 weakref.ref，当对象加入 WeakSet 的时候，使用 weakref.ref 封装，指定的 callback 函数就是从 WeakSet 中删除。感兴趣的话可以直接看源码（_weakrefset.py），下面给出一个参考例子：
1 # -*- coding: utf-8 -*- 2 import weakref 3 class OBJ(object): 4 def f(self): 5 print 'HELLO' 6 7 if __name__ == '__main__': 8 o = OBJ() 9 ws = weakref.WeakSet() 10 ws.add(o) 11 print len(ws) # 1 12 del o 13 print len(ws) # 0
（4）weakref.WeakValueDictionary， weakref.WeakKeyDictionary
实现原理和使用方法基本同 WeakSet
总结
本文的篇幅略长，首选是简单介绍了 python 的内存管理，重点介绍了引用计数与垃圾回收，然后阐述 Python 中内存泄露与循环引用产生的原因与危害，最后是利用 gc、objgraph、weakref 等工具来分析并解决内存泄露、循环引用问题。