为提升执⾏行性能,Python 在内存管理上做了⼤大量⼯工作。最直接的做法就是⽤用内存池来减少操作系
统内存分配和回收操作,那些⼩小于等于 256 字节对象,将直接从内存池中获取存储空间。
根据需要,虚拟机每次从操作系统申请⼀一块 256KB,取名为 arena 的⼤大块内存。并按系统⻚页⼤大
⼩小,划分成多个 pool。每个 pool 继续分割成 n 个⼤大⼩小相同的 block,这是内存池最⼩小存储单位。
14
block ⼤大⼩小是 8 的倍数,也就是说存储 13 字节⼤大⼩小的对象,需要找 block ⼤大⼩小为 16 的 pool 获
取空闲块。所有这些都⽤用头信息和链表管理起来,以便快速查找空闲区域进⾏行分配。
⼤大于 256 字节的对象,直接⽤用 malloc 在堆上分配内存。程序运⾏行中的绝⼤大多数对象都⼩小于这个阈
值,因此内存池策略可有效提升性能。
当所有 arena 的总容量超出限制 (64MB) 时,就不再请求新的 arena 内存。⽽而是如同 "⼤大对象" ⼀一
样,直接在堆上为对象分配内存。另外,完全空闲的 arena 会被释放,其内存交还给操作系统。
引⽤用传递
对象总是按引⽤用传递,简单点说就是通过复制指针来实现多个名字指向同⼀一对象。因为 arena 也是
在堆上分配的,所以⽆无论何种类型何种⼤大⼩小的对象,都存储在堆上。Python 没有值类型和引⽤用类
型⼀一说,就算是最简单的整数也是拥有标准头的完整对象。
>>> a = object()
>>> b = a
>>> a is b
True
>>> hex(id(a)), hex(id(b))? ? ? # 地址相同,意味着对象是同⼀一个。
('0x10b1f5640', '0x10b1f5640')
>>> def test(x):? ? ? ?
... print hex(id(x))? ? ?
>>> test(a)
0x10b1f5640? ? ? ? ? # 地址依旧相同。
如果不希望对象被修改,就需使⽤用不可变类型,或对象复制品。
不可变类型:int, long, str, tuple, frozenset
除了某些类型⾃自带的 copy ⽅方法外,还可以:
• 使⽤用标准库的 copy 模块进⾏行深度复制。
• 序列化对象,如 pickle、cPickle、marshal。
下⾯面的测试建议不要⽤用数字等不可变对象,因为其内部的缓存和复⽤用机制可能会造成干扰。
>>> import copy
>>> x = object()
>>> l = [x]? ? ? ? # 创建⼀一个列表。
15
>>> l2 = copy.copy(l)? ? # 浅复制,仅复制对象⾃自⾝身,⽽而不会递归复制其成员。
>>> l2 is l? ? ? ? # 可以看到复制列表的元素依然是原对象。
False
>>> l2[0] is x
True
>>> l3 = copy.deepcopy(l)?? # 深度复制,会递归复制所有深度成员。
>>> l3 is l? ? ? ? # 列表元素也被复制了。
False
>>> l3[0] is x
False
循环引⽤用会影响 deepcopy 函数的运作,建议查阅官⽅方标准库⽂文档。
引⽤用计数
Python 默认采⽤用引⽤用计数来管理对象的内存回收。当引⽤用计数为 0 时,将⽴立即回收该对象内存,
要么将对应的 block 块标记为空闲,要么返还给操作系统。
为观察回收⾏行为,我们⽤用 __del__ 监控对象释放。
>>> class User(object):
... def __del__(self):
... print "Will be dead!"
>>> a = User()
>>> b = a
>>> import sys
>>> sys.getrefcount(a)
3
>>> del a? ? ? ? # 删除引⽤用,计数减⼩小。
>>> sys.getrefcount(b)
2
>>> del b? ? ? ? # 删除最后⼀一个引⽤用,计数器为 0,对象被回收。
Will be dead!
某些内置类型,⽐比如⼩小整数,因为缓存的缘故,计数永远不会为 0,直到进程结束才由虚拟机清理
函数释放。
除了直接引⽤用外,Python 还⽀支持弱引⽤用。允许在不增加引⽤用计数,不妨碍对象回收的情况下间接
引⽤用对象。但不是所有类型都⽀支持弱引⽤用,⽐比如 list、dict ,弱引⽤用会引发异常。
16
改⽤用弱引⽤用回调监控对象回收。
>>> import sys, weakref
>>> class User(object): pass
>>> def callback(r):? ? ? # 回调函数会在原对象被回收时调⽤用。
... print "weakref object:", r
... print "target object dead!"
>>> a = User()
>>> r = weakref.ref(a, callback)?? # 创建弱引⽤用对象。
>>> sys.getrefcount(a)? ? ? # 可以看到弱引⽤用没有导致⺫⽬目标对象引⽤用计数增加。
2? ? ? ? ? ? # 计数 2 是因为 getrefcount 形参造成的。
>>> r() is a?? ? ? ? # 透过弱引⽤用可以访问原对象。
True
>>> del a? ? ? ? ? # 原对象回收,callback 被调⽤用。
weakref object: <weakref at 0x10f99a368; dead>
target object dead!
>>> hex(id(r))? ? ? ? # 通过对⽐比,可以看到 callback 参数是弱引⽤用对象。
'0x10f99a368'? ? ? ? ? # 因为原对象已经死亡。
>>> r() is None? ? ? ? # 此时弱引⽤用只能返回 None。也可以此判断原对象死亡。
True
引⽤用计数是⼀一种简单直接,并且⼗十分⾼高效的内存回收⽅方式。⼤大多数时候它都能很好地⼯工作,除了循
环引⽤用造成计数故障。简单明显的循环引⽤用,可以⽤用弱引⽤用打破循环关系。但在实际开发中,循环
引⽤用的形成往往很复杂,可能由 n 个对象间接形成⼀一个⼤大的循环体,此时只有靠 GC 去回收了。
垃圾回收
事实上,Python 拥有两套垃圾回收机制。除了引⽤用计数,还有个专⻔门处理循环引⽤用的 GC。通常我
们提到垃圾回收时,都是指这个 "Reference Cycle Garbage Collection"。
能引发循环引⽤用问题的,都是那种容器类对象,⽐比如 list、set、object 等。对于这类对象,虚拟
机在为其分配内存时,会额外添加⽤用于追踪的 PyGC_Head。这些对象被添加到特殊链表⾥里,以便
GC 进⾏行管理。
typedef union _gc_head {
struct {
union _gc_head *gc_next;
17
union _gc_head *gc_prev;
Py_ssize_t gc_refs;
} gc;
long double dummy;
} PyGC_Head;
当然,这并不表⽰示此类对象⾮非得 GC 才能回收。如果不存在循环引⽤用,⾃自然是积极性更⾼高的引⽤用计
数机制抢先给处理掉。也就是说,只要不存在循环引⽤用,理论上可以禁⽤用 GC。当执⾏行某些密集运
算时,临时关掉 GC 有助于提升性能。
>>> import gc
>>> class User(object):
... def __del__(self):
... print hex(id(self)), "will be dead!"
>>> gc.disable()? ? ? ? # 关掉 GC
>>> a = User()? ? ?
>>> del a? ? ? ? ? # 对象正常回收,引⽤用计数不会依赖 GC。
0x10fddf590 will be dead!
同 .NET、JAVA ⼀一样,Python GC 同样将要回收的对象分成 3 级代龄。GEN0 管理新近加⼊入的年
轻对象,GEN1 则是在上次回收后依然存活的对象,剩下 GEN2 存储的都是⽣生命周期极⻓长的家伙。
每级代龄都有⼀一个最⼤大容量阈值,每次 GEN0 对象数量超出阈值时,都将引发垃圾回收操作。
#define NUM_GENERATIONS 3
/* linked lists of container objects */
static struct gc_generation generations[NUM_GENERATIONS] = {
/* PyGC_Head, threshold, count */
{{{GEN_HEAD(0), GEN_HEAD(0), 0}}, 700, 0},
{{{GEN_HEAD(1), GEN_HEAD(1), 0}}, 10, 0},
{{{GEN_HEAD(2), GEN_HEAD(2), 0}}, 10, 0},
};
GC ⾸首先检查 GEN2,如阈值被突破,那么合并 GEN2、GEN1、GEN0 ⼏几个追踪链表。如果没有超
出,则检查 GEN1。GC 将存活的对象提升代龄,⽽而那些可回收对象则被打破循环引⽤用,放到专⻔门
的列表等待回收。
>>> gc.get_threshold()? ? # 获取各级代龄阈值
(700, 10, 10)
>>> gc.get_count()? ? ? # 各级代龄链表跟踪的对象数量
(203, 0, 5)
包含 __del__ ⽅方法的循环引⽤用对象,永远不会被 GC 回收,直⾄至进程终⽌止。
18
这回不能偷懒⽤用 __del__ 监控对象回收了,改⽤用 weakref。因 IPython 对 GC 存在干扰,下⾯面的测
试代码建议在原⽣生 shell 中进⾏行。
>>> import gc, weakref
>>> class User(object): pass
>>> def callback(r): print r, "dead"
>>> gc.disable()? ? ? ? ? # 停掉 GC,看看引⽤用计数的能⼒力。
>>> a = User(); wa = weakref.ref(a, callback)
>>> b = User(); wb = weakref.ref(b, callback)
>>> a.b = b; b.a = a? ? ? ? # 形成循环引⽤用关系。
>>> del a; del b? ? ? ? ? # 删除名字引⽤用。
>>> wa(), wb()? ? ? ? ? # 显然,计数机制对循环引⽤用⽆无效。
(<__main__.User object at 0x1045f4f50>, <__main__.User object at 0x1045f4f90>)
>>> gc.enable()? ? ? ? ? # 开启 GC。
>>> gc.isenabled()? ? ? ? ? # 可以⽤用 isenabled 确认。
True
>>> gc.collect()? ? ? ? ? # 因为没有达到阈值,我们⼿手⼯工启动回收。
<weakref at 0x1045a8cb0; dead> dead? ? # GC 的确有对付基友的能⼒力。? ?
<weakref at 0x1045a8db8; dead> dead? ? # 这个地址是弱引⽤用对象的,别犯糊涂。
⼀一旦有了 __del__,GC 就拿循环引⽤用没办法了。
>>> import gc, weakref
>>> class User(object):
... def __del__(self): pass? ? ? ? # 难道连空的 __del__ 也不⾏行?
>>> def callback(r): print r, "dead!"
>>> gc.set_debug(gc.DEBUG_STATS | gc.DEBUG_LEAK)? # 输出更详细的回收状态信息。
>>> gc.isenabled()? ? ? ? ? ? # 确保 GC 在⼯工作。
True
>>> a = User(); wa = weakref.ref(a, callback)
>>> b = User(); wb = weakref.ref(b, callback)
>>> a.b = b; b.a = a
>>> del a; del b
>>> gc.collect()? ? ? ? ? ? # 从输出信息看,回收失败。
gc: collecting generation 2...
19
gc: objects in each generation: 520 3190 0
gc: uncollectable <User 0x10fd51fd0>? ? ? # a
gc: uncollectable <User 0x10fd57050>? ? ? # b
gc: uncollectable <dict 0x7f990ac88280>? ? ? # a.__dict__
gc: uncollectable <dict 0x7f990ac88940>? ? ? # b.__dict__
gc: done, 4 unreachable, 4 uncollectable, 0.0014s elapsed.
4
>>> xa = wa()
>>> xa, hex(id(xa.__dict__))
<__main__.User object at 0x10fd51fd0>, '0x7f990ac88280',
>>> xb = wb()
>>> xb, hex(id(xb.__dict__))
<__main__.User object at 0x10fd57050>, '0x7f990ac88940'
关于⽤用不⽤用 __del__ 的争论很多。⼤大多数⼈人的结论是坚决抵制,诸多 "⽜牛⼈人" 也是这样教导新⼿手的。
可毕竟 __del__ 承担了析构函数的⾓角⾊色,某些时候还是有其特定的作⽤用的。⽤用弱引⽤用回调会造成逻
辑分离,不便于维护。对于⼀一些简单的脚本,我们还是能保证避免循环引⽤用的,那不妨试试。就像
前⾯面例⼦子中⽤用来监测对象回收,就很⽅方便。
统内存分配和回收操作,那些⼩小于等于 256 字节对象,将直接从内存池中获取存储空间。
根据需要,虚拟机每次从操作系统申请⼀一块 256KB,取名为 arena 的⼤大块内存。并按系统⻚页⼤大
⼩小,划分成多个 pool。每个 pool 继续分割成 n 个⼤大⼩小相同的 block,这是内存池最⼩小存储单位。
14
block ⼤大⼩小是 8 的倍数,也就是说存储 13 字节⼤大⼩小的对象,需要找 block ⼤大⼩小为 16 的 pool 获
取空闲块。所有这些都⽤用头信息和链表管理起来,以便快速查找空闲区域进⾏行分配。
⼤大于 256 字节的对象,直接⽤用 malloc 在堆上分配内存。程序运⾏行中的绝⼤大多数对象都⼩小于这个阈
值,因此内存池策略可有效提升性能。
当所有 arena 的总容量超出限制 (64MB) 时,就不再请求新的 arena 内存。⽽而是如同 "⼤大对象" ⼀一
样,直接在堆上为对象分配内存。另外,完全空闲的 arena 会被释放,其内存交还给操作系统。
引⽤用传递
对象总是按引⽤用传递,简单点说就是通过复制指针来实现多个名字指向同⼀一对象。因为 arena 也是
在堆上分配的,所以⽆无论何种类型何种⼤大⼩小的对象,都存储在堆上。Python 没有值类型和引⽤用类
型⼀一说,就算是最简单的整数也是拥有标准头的完整对象。
>>> a = object()
>>> b = a
>>> a is b
True
>>> hex(id(a)), hex(id(b))? ? ? # 地址相同,意味着对象是同⼀一个。
('0x10b1f5640', '0x10b1f5640')
>>> def test(x):? ? ? ?
... print hex(id(x))? ? ?
>>> test(a)
0x10b1f5640? ? ? ? ? # 地址依旧相同。
如果不希望对象被修改,就需使⽤用不可变类型,或对象复制品。
不可变类型:int, long, str, tuple, frozenset
除了某些类型⾃自带的 copy ⽅方法外,还可以:
• 使⽤用标准库的 copy 模块进⾏行深度复制。
• 序列化对象,如 pickle、cPickle、marshal。
下⾯面的测试建议不要⽤用数字等不可变对象,因为其内部的缓存和复⽤用机制可能会造成干扰。
>>> import copy
>>> x = object()
>>> l = [x]? ? ? ? # 创建⼀一个列表。
15
>>> l2 = copy.copy(l)? ? # 浅复制,仅复制对象⾃自⾝身,⽽而不会递归复制其成员。
>>> l2 is l? ? ? ? # 可以看到复制列表的元素依然是原对象。
False
>>> l2[0] is x
True
>>> l3 = copy.deepcopy(l)?? # 深度复制,会递归复制所有深度成员。
>>> l3 is l? ? ? ? # 列表元素也被复制了。
False
>>> l3[0] is x
False
循环引⽤用会影响 deepcopy 函数的运作,建议查阅官⽅方标准库⽂文档。
引⽤用计数
Python 默认采⽤用引⽤用计数来管理对象的内存回收。当引⽤用计数为 0 时,将⽴立即回收该对象内存,
要么将对应的 block 块标记为空闲,要么返还给操作系统。
为观察回收⾏行为,我们⽤用 __del__ 监控对象释放。
>>> class User(object):
... def __del__(self):
... print "Will be dead!"
>>> a = User()
>>> b = a
>>> import sys
>>> sys.getrefcount(a)
3
>>> del a? ? ? ? # 删除引⽤用,计数减⼩小。
>>> sys.getrefcount(b)
2
>>> del b? ? ? ? # 删除最后⼀一个引⽤用,计数器为 0,对象被回收。
Will be dead!
某些内置类型,⽐比如⼩小整数,因为缓存的缘故,计数永远不会为 0,直到进程结束才由虚拟机清理
函数释放。
除了直接引⽤用外,Python 还⽀支持弱引⽤用。允许在不增加引⽤用计数,不妨碍对象回收的情况下间接
引⽤用对象。但不是所有类型都⽀支持弱引⽤用,⽐比如 list、dict ,弱引⽤用会引发异常。
16
改⽤用弱引⽤用回调监控对象回收。
>>> import sys, weakref
>>> class User(object): pass
>>> def callback(r):? ? ? # 回调函数会在原对象被回收时调⽤用。
... print "weakref object:", r
... print "target object dead!"
>>> a = User()
>>> r = weakref.ref(a, callback)?? # 创建弱引⽤用对象。
>>> sys.getrefcount(a)? ? ? # 可以看到弱引⽤用没有导致⺫⽬目标对象引⽤用计数增加。
2? ? ? ? ? ? # 计数 2 是因为 getrefcount 形参造成的。
>>> r() is a?? ? ? ? # 透过弱引⽤用可以访问原对象。
True
>>> del a? ? ? ? ? # 原对象回收,callback 被调⽤用。
weakref object: <weakref at 0x10f99a368; dead>
target object dead!
>>> hex(id(r))? ? ? ? # 通过对⽐比,可以看到 callback 参数是弱引⽤用对象。
'0x10f99a368'? ? ? ? ? # 因为原对象已经死亡。
>>> r() is None? ? ? ? # 此时弱引⽤用只能返回 None。也可以此判断原对象死亡。
True
引⽤用计数是⼀一种简单直接,并且⼗十分⾼高效的内存回收⽅方式。⼤大多数时候它都能很好地⼯工作,除了循
环引⽤用造成计数故障。简单明显的循环引⽤用,可以⽤用弱引⽤用打破循环关系。但在实际开发中,循环
引⽤用的形成往往很复杂,可能由 n 个对象间接形成⼀一个⼤大的循环体,此时只有靠 GC 去回收了。
垃圾回收
事实上,Python 拥有两套垃圾回收机制。除了引⽤用计数,还有个专⻔门处理循环引⽤用的 GC。通常我
们提到垃圾回收时,都是指这个 "Reference Cycle Garbage Collection"。
能引发循环引⽤用问题的,都是那种容器类对象,⽐比如 list、set、object 等。对于这类对象,虚拟
机在为其分配内存时,会额外添加⽤用于追踪的 PyGC_Head。这些对象被添加到特殊链表⾥里,以便
GC 进⾏行管理。
typedef union _gc_head {
struct {
union _gc_head *gc_next;
17
union _gc_head *gc_prev;
Py_ssize_t gc_refs;
} gc;
long double dummy;
} PyGC_Head;
当然,这并不表⽰示此类对象⾮非得 GC 才能回收。如果不存在循环引⽤用,⾃自然是积极性更⾼高的引⽤用计
数机制抢先给处理掉。也就是说,只要不存在循环引⽤用,理论上可以禁⽤用 GC。当执⾏行某些密集运
算时,临时关掉 GC 有助于提升性能。
>>> import gc
>>> class User(object):
... def __del__(self):
... print hex(id(self)), "will be dead!"
>>> gc.disable()? ? ? ? # 关掉 GC
>>> a = User()? ? ?
>>> del a? ? ? ? ? # 对象正常回收,引⽤用计数不会依赖 GC。
0x10fddf590 will be dead!
同 .NET、JAVA ⼀一样,Python GC 同样将要回收的对象分成 3 级代龄。GEN0 管理新近加⼊入的年
轻对象,GEN1 则是在上次回收后依然存活的对象,剩下 GEN2 存储的都是⽣生命周期极⻓长的家伙。
每级代龄都有⼀一个最⼤大容量阈值,每次 GEN0 对象数量超出阈值时,都将引发垃圾回收操作。
#define NUM_GENERATIONS 3
/* linked lists of container objects */
static struct gc_generation generations[NUM_GENERATIONS] = {
/* PyGC_Head, threshold, count */
{{{GEN_HEAD(0), GEN_HEAD(0), 0}}, 700, 0},
{{{GEN_HEAD(1), GEN_HEAD(1), 0}}, 10, 0},
{{{GEN_HEAD(2), GEN_HEAD(2), 0}}, 10, 0},
};
GC ⾸首先检查 GEN2,如阈值被突破,那么合并 GEN2、GEN1、GEN0 ⼏几个追踪链表。如果没有超
出,则检查 GEN1。GC 将存活的对象提升代龄,⽽而那些可回收对象则被打破循环引⽤用,放到专⻔门
的列表等待回收。
>>> gc.get_threshold()? ? # 获取各级代龄阈值
(700, 10, 10)
>>> gc.get_count()? ? ? # 各级代龄链表跟踪的对象数量
(203, 0, 5)
包含 __del__ ⽅方法的循环引⽤用对象,永远不会被 GC 回收,直⾄至进程终⽌止。
18
这回不能偷懒⽤用 __del__ 监控对象回收了,改⽤用 weakref。因 IPython 对 GC 存在干扰,下⾯面的测
试代码建议在原⽣生 shell 中进⾏行。
>>> import gc, weakref
>>> class User(object): pass
>>> def callback(r): print r, "dead"
>>> gc.disable()? ? ? ? ? # 停掉 GC,看看引⽤用计数的能⼒力。
>>> a = User(); wa = weakref.ref(a, callback)
>>> b = User(); wb = weakref.ref(b, callback)
>>> a.b = b; b.a = a? ? ? ? # 形成循环引⽤用关系。
>>> del a; del b? ? ? ? ? # 删除名字引⽤用。
>>> wa(), wb()? ? ? ? ? # 显然,计数机制对循环引⽤用⽆无效。
(<__main__.User object at 0x1045f4f50>, <__main__.User object at 0x1045f4f90>)
>>> gc.enable()? ? ? ? ? # 开启 GC。
>>> gc.isenabled()? ? ? ? ? # 可以⽤用 isenabled 确认。
True
>>> gc.collect()? ? ? ? ? # 因为没有达到阈值,我们⼿手⼯工启动回收。
<weakref at 0x1045a8cb0; dead> dead? ? # GC 的确有对付基友的能⼒力。? ?
<weakref at 0x1045a8db8; dead> dead? ? # 这个地址是弱引⽤用对象的,别犯糊涂。
⼀一旦有了 __del__,GC 就拿循环引⽤用没办法了。
>>> import gc, weakref
>>> class User(object):
... def __del__(self): pass? ? ? ? # 难道连空的 __del__ 也不⾏行?
>>> def callback(r): print r, "dead!"
>>> gc.set_debug(gc.DEBUG_STATS | gc.DEBUG_LEAK)? # 输出更详细的回收状态信息。
>>> gc.isenabled()? ? ? ? ? ? # 确保 GC 在⼯工作。
True
>>> a = User(); wa = weakref.ref(a, callback)
>>> b = User(); wb = weakref.ref(b, callback)
>>> a.b = b; b.a = a
>>> del a; del b
>>> gc.collect()? ? ? ? ? ? # 从输出信息看,回收失败。
gc: collecting generation 2...
19
gc: objects in each generation: 520 3190 0
gc: uncollectable <User 0x10fd51fd0>? ? ? # a
gc: uncollectable <User 0x10fd57050>? ? ? # b
gc: uncollectable <dict 0x7f990ac88280>? ? ? # a.__dict__
gc: uncollectable <dict 0x7f990ac88940>? ? ? # b.__dict__
gc: done, 4 unreachable, 4 uncollectable, 0.0014s elapsed.
4
>>> xa = wa()
>>> xa, hex(id(xa.__dict__))
<__main__.User object at 0x10fd51fd0>, '0x7f990ac88280',
>>> xb = wb()
>>> xb, hex(id(xb.__dict__))
<__main__.User object at 0x10fd57050>, '0x7f990ac88940'
关于⽤用不⽤用 __del__ 的争论很多。⼤大多数⼈人的结论是坚决抵制,诸多 "⽜牛⼈人" 也是这样教导新⼿手的。
可毕竟 __del__ 承担了析构函数的⾓角⾊色,某些时候还是有其特定的作⽤用的。⽤用弱引⽤用回调会造成逻
辑分离,不便于维护。对于⼀一些简单的脚本,我们还是能保证避免循环引⽤用的,那不妨试试。就像
前⾯面例⼦子中⽤用来监测对象回收,就很⽅方便。