Python垃圾回收机制
Posted BGPY
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了Python垃圾回收机制相关的知识,希望对你有一定的参考价值。
对于Python垃圾回收机制主要有三个,首先是使用引用计数来跟踪和回收垃圾,为了解决循环
引用问题,就采用标记-清除的方法,标记-清除的方法所带来的额外操作实际上与系统中总的内存
块的总数是相关的,当需要回收的内存块越多,垃圾检查带来的额外操作就越多,为了提高垃圾收集
的效率,采用“空间换时间的策略”,即使用分代机制,对于长时间没有被回收的内存就减少对它的
垃圾回收频率。
首先看一下Python的内存管理架构:
layer 3: Object-specific memory(int/dict/list/string....) Python 实现并维护 更高抽象层次的内存管理策略, 主要是各类特定对象的缓冲池机制 layer 2: Python\'s object allocator Python 实现并维护 实现了创建/销毁Python对象的接口(PyObject_New/Del), 涉及对象参数/引用计数等 layer 1: Python\'s raw memory allocator (PyMem_ API) Python 实现并维护, 包装了第0层的内存管理接口, 提供统一的raw memory管理接口 封装的原因: 不同操作系统行为不一定一致, 保证可移植性, 相同语义相同行为 layer 0: Underlying general-purpose allocator (ex: C library malloc) 操作系统提供的内存管理接口, 由操作系统实现并管理, Python不能干涉这一层的行为
引用计数机制
引用计数是一种垃圾收集机制,而且也是一种最直观,最简单的垃圾回收技术 当一个对象的引用被创建或者复制时,对象的引用计数加1;
当一个对象的引用被销毁 对象的引用计数减1。如果对象的引用计数减少为0,那么就意味着对象已经不会被任何人使用,可以将其所占有的内存释放。
引用计数机制的优点:实时性,对于任何内存一旦没有指向它的引用,就会立即被回收(这里需要满足阈值才可以)
引用计数机制的缺点:引用计数机制所带来的维护引用计数的额外操作与Python运行中所运行的内存分配和释放,引用赋值的
次数是成正比的,为了与引用计数机制搭配,在内存的分配和释放上获得最高的效率,Python设计了大量的
内存池机制,减少运行期间malloc和free的操作。
>>> from sys import getrefcount >>> a = [1,2,3] >>> getrefcount(a) 2 >>> b =a >>> getrefcount(a) 3 >>>
标记-清除机制
引用计数机制有个致命的弱点,就是可能存在循环引用的问题:
一组对象的引用计数都不为0,然而这些对象实际上并没有被任何外部变量引用,它们之间只是相互引用,这意味这个不会
有人使用这组对象,应该回收这些对象所占的内存,然后由于互相引用的存在, 每个对象的引用计数都不为0,因此这些对象
所占用的内存永远不会被回收。
标记-清除机制就是为了解决循环引用的问题。首先只有container对象之间才会产生循环引用,所谓container对象即是内部
可持有对其他对象的引用的对象,比如list、dict、class等,而像PyIntObject、PyStringObject这些是绝不可能产生循环引用的
所以Python的垃圾回收机制运行时,只需要检查这些container对象,为了跟踪每个container,需要将这些对象组织到一个集合中。
Python采用了一个双向链表,所以的container对象在创建之后,就会被插入到这个链表中。这个链表也叫作可收集对象链表。
为了解决循环引用的问题,提出了有效引用计数的概念,即循环引用的两个对象引用计数不为0,实际上有效的引用计数为0
假设两个对象为A、B,我们从A出发,因为它有一个对B的引用,则将B的引用计数减1;然后顺着引用达到B,因为B有一个对A的引用,
同样将A的引用减1,这样,就完成了循环引用对象间环摘除。但是这样直接修改真实的引用计数,可能存在悬空引用的问题。
所以采用修改计数计数副本的方法。
这个计数副本的唯一作用是寻找root object集合(该集合中的对象是不能被回收的)。当成功寻找到root object集合之后,
我们就可以从root object出发,沿着引用链,一个接一个的标记不能回收的内存。首先将现在的内存链表一分为二,
一条链表中维护root object集合,成为root链表,而另外一条链表中维护剩下的对象,成为unreachable链表。之所以要剖成两个链表,
是基于这样的一种考虑:现在的unreachable可能存在被root链表中的对象,直接或间接引用的对象,这些对象是不能被回收的,
一旦在标记的过程中,发现这样的对象,就将其从unreachable链表中移到root链表中;当完成标记后,unreachable链表中剩下
的所有对象就是名副其实的垃圾对象了,接下来的垃圾回收只需限制在unreachable链表中即可。
分代回收
分代回收的思想:将系统中的所有内存块根据其存活时间划分为不同的集合,每一个集合就称为一个“代”
垃圾收集的频率随着“代”的存活时间的增大而减小,也就是说,活的越长的对象,就越可能不是垃圾,就应该
越少去收集。当某一代对象经历过垃圾回收,依然存活,那么它就被归入下一代中。
在Python中总共有三个“代”,每个代其实就是上文中所提到的一条可收集对象链表。下面的数组就是用于分代
垃圾收集的三个“代”。
#define NUM_GENERATIONS 3 #define GEN_HEAD(n) (&generations[n].head) // 三代都放到这个数组中 /* 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}, //700个container, 超过立即触发垃圾回收机制 {{{GEN_HEAD(1), GEN_HEAD(1), 0}}, 10, 0}, // 10个 {{{GEN_HEAD(2), GEN_HEAD(2), 0}}, 10, 0}, // 10个 }; PyGC_Head *_PyGC_generation0 = GEN_HEAD(0);
其中存在三个阈值,分别是700,10,10
可以通过get_threshold()方法获得阈值:
import gc print(gc.get_threshold()) (700, 10, 10)
其中第一个阈值表示第0代链表最多可以容纳700个container对象,超过了这个极限值,就会立即出发垃圾回收机制。
后面两个阈值10是分代有关系,就是每10次0代垃圾回收,会配合1次1代的垃圾回收;而每10次1代的垃圾回收,
才会有1次的2代垃圾回收。也就是空间换时间的体现。
垃圾回收的流程:
--> 分配内存的时候发现超过阈值(第0代的container个数),触发垃圾回收
--> 将所有可收集对象链表放在一起(将比当前处理的“代”更年轻的"代"的链表合并到当前”代“中)
--> 计算有效引用计数
--> 根据有效引用计数分为计数等于0和大于0两个集合
--> 引用计数大于0的对象,放入下一代
--> 引用计数等于0的对象,执行回收
--> 回收遍历容器内的各个元素, 减掉对应元素引用计数(破掉循环引用)
--> python底层内存管理机制回收内存
参考文档:
http://www.cnblogs.com/vamei/p/3232088.html
http://python.jobbole.com/83548/
http://python.jobbole.com/82061/
python源码剖析
以上是关于Python垃圾回收机制的主要内容,如果未能解决你的问题,请参考以下文章