Python 中的垃圾回收机制 - Python - 伯乐在线
& Python 中的垃圾回收机制
GC作为现代编程语言的自动内存管理机制，专注于两件事：1. 找到内存中无用的垃圾资源 2. 清除这些垃圾并把内存让出来给其他对象使用。GC彻底把程序员从资源管理的重担中解放出来，让他们有更多的时间放在业务逻辑上。但这并不意味着码农就可以不去了解GC，毕竟多了解GC知识还是有利于我们写出更健壮的代码。
Python语言默认采用的垃圾收集机制是『引用计数法 Reference Counting』，该算法最早George E. Collins在1960的时候首次提出，50年后的今天，该算法依然被很多编程语言使用，『引用计数法』的原理是：每个对象维护一个ob_ref字段，用来记录该对象当前被引用的次数，每当新的引用指向该对象时，它的引用计数ob_ref加1，每当该对象的引用失效时计数ob_ref减1，一旦对象的引用计数为0，该对象立即被回收，对象占用的内存空间将被释放。它的缺点是需要额外的空间维护引用计数，这个问题是其次的，不过最主要的问题是它不能解决对象的“循环引用”，因此，也有很多语言比如Java并没有采用该算法做来垃圾的收集机制。
什么是循环引用？A和B相互引用而再没有外部引用A与B中的任何一个，它们的引用计数虽然都为1，但显然应该被回收，例子：
a = { } #对象A的引用计数为 1
b = { } #对象B的引用计数为 1
a['b'] = b
#B的引用计数增1
b['a'] = a
#A的引用计数增1
del a #A的引用减 1，最后A对象的引用为 1
del b #B的引用减 1, 最后B对象的引用为 1
a = { } #对象A的引用计数为 1b = { } #对象B的引用计数为 1a['b'] = b&&#B的引用计数增1b['a'] = a&&#A的引用计数增1del a #A的引用减 1，最后A对象的引用为 1del b #B的引用减 1, 最后B对象的引用为 1
在这个例子中程序执行完del语句后，A、B对象已经没有任何引用指向这两个对象，但是这两个对象各包含一个对方对象的引用，虽然最后两个对象都无法通过其它变量来引用这两个对象了，这对GC来说就是两个非活动对象或者说是垃圾对象，但是他们的引用计数并没有减少到零。因此如果是使用引用计数法来管理这两对象的话，他们并不会被回收，它会一直驻留在内存中，就会造成了内存泄漏（内存空间在使用完毕后未释放）。为了解决对象的循环引用问题，Python引入了标记-清除和分代回收两种GC机制。
『标记清除（Mark—Sweep）』算法是一种基于追踪回收（tracing GC）技术实现的垃圾回收算法。它分为两个阶段：第一阶段是标记阶段，GC会把所有的『活动对象』打上标记，第二阶段是把那些没有标记的对象『非活动对象』进行回收。那么GC又是如何判断哪些是活动对象哪些是非活动对象的呢？
对象之间通过引用（指针）连在一起，构成一个有向图，对象构成这个有向图的节点，而引用关系构成这个有向图的边。从根对象（root object）出发，沿着有向边遍历对象，可达的（reachable）对象标记为活动对象，不可达的对象就是要被清除的非活动对象。根对象就是全局变量、调用栈、寄存器。
在上图中，我们把小黑圈视为全局变量，也就是把它作为root object，从小黑圈出发，对象1可直达，那么它将被标记，对象2、3可间接到达也会被标记，而4和5不可达，那么1、2、3就是活动对象，4和5是非活动对象会被GC回收。
标记清除算法作为Python的辅助垃圾收集技术主要处理的是一些容器对象，比如list、dict、tuple，instance等，因为对于字符串、数值对象是不可能造成循环引用问题。Python使用一个双向链表将这些容器对象组织起来。不过，这种简单粗暴的标记清除算法也有明显的缺点：清除非活动的对象前它必须顺序扫描整个堆内存，哪怕只剩下小部分活动对象也要扫描所有对象。
分代回收是一种以空间换时间的操作方式，Python将内存根据对象的存活时间划分为不同的集合，每个集合称为一个代，Python将内存分为了3“代”，分别为年轻代（第0代）、中年代（第1代）、老年代（第2代），他们对应的是3个链表，它们的垃圾收集频率与对象的存活时间的增大而减小。新创建的对象都会分配在年轻代，年轻代链表的总数达到上限时，Python垃圾收集机制就会被触发，把那些可以被回收的对象回收掉，而那些不会回收的对象就会被移到中年代去，依此类推，老年代中的对象是存活时间最久的对象，甚至是存活于整个系统的生命周期内。同时，分代回收是建立在标记清除技术基础之上。分代回收同样作为Python的辅助垃圾收集技术处理那些容器对象
《垃圾回收的算法与实现》
《Python源码剖析》https://kuaibao.qq.com/s/OU7Y00?refer=cp_1026分享分享快讯到朋友圈分享快讯到 QQ分享快讯到 QQ 空间分享快讯到微博复制快讯链接到剪贴板扫描二维码扫描关注云+社区最新快讯分享快讯到朋友圈分享快讯到 QQ分享快讯到 QQ 空间分享快讯到微博复制快讯链接到剪贴板分享快讯到朋友圈分享快讯到 QQ分享快讯到 QQ 空间分享快讯到微博复制快讯链接到剪贴板分享快讯到朋友圈分享快讯到 QQ分享快讯到 QQ 空间分享快讯到微博复制快讯链接到剪贴板分享快讯到朋友圈分享快讯到 QQ分享快讯到 QQ 空间分享快讯到微博复制快讯链接到剪贴板分享快讯到朋友圈分享快讯到 QQ分享快讯到 QQ 空间分享快讯到微博复制快讯链接到剪贴板分享快讯到朋友圈分享快讯到 QQ分享快讯到 QQ 空间分享快讯到微博复制快讯链接到剪贴板分享快讯到朋友圈分享快讯到 QQ分享快讯到 QQ 空间分享快讯到微博复制快讯链接到剪贴板分享快讯到朋友圈分享快讯到 QQ分享快讯到 QQ 空间分享快讯到微博复制快讯链接到剪贴板分享快讯到朋友圈分享快讯到 QQ分享快讯到 QQ 空间分享快讯到微博复制快讯链接到剪贴板分享快讯到朋友圈分享快讯到 QQ分享快讯到 QQ 空间分享快讯到微博复制快讯链接到剪贴板扫描二维码扫描关注云+社区Python的GC模块主要运用了&引用计数&（reference counting）来跟踪和回收垃圾。在引用计数的基础上，还可以通过&标记-清除&（mark and sweep）解决容器对象可能产生的循环引用的问题。通过&分代回收&（generation collection）以空间换取时间来进一步提高垃圾回收的效率。
引用计数机制：
&&&&python里每一个东西都是对象，它们的核心就是一个结构体：PyObject
1 typedef struct_object {
struct_typeobject *ob_
PyObject是每个对象必有的内容，其中ob_refcnt就是做为引用计数。当一个对象有新的引用时，它的ob_refcnt就会增加，当引用它的对象被删除，它的ob_refcnt就会减少
1 #define Py_INCREF(op)
((op)-&ob_refcnt++)
//增加计数
2 #define Py_DECREF(op)
//减少计数
if (--(op)-&ob_refcnt != 0)
__Py_Dealloc((PyObject *)(op))
引用计数为0时，该对象生命就结束了。
&&&&引用计数机制的优点：
& & & & &1、简单
&&&&& & 2、实时性：一旦没有引用，内存就直接释放了。不用像其他机制等到特定时机。实时性还带来一个好处：处理回收内存的时间分摊到了平时。& &&& &&
&&&&引用计数机制的缺点：&
&&&&& & 1、维护引用计数消耗资源&
&&&&& & 2、循环引用&
1 list1 = []
2 list2 = []
3 list1.append(list2)
4 list2.append(list1)
list1与list2相互引用，如果不存在其他对象对它们的引用，list1与list2的引用计数也仍然为1，所占用的内存永远无法被回收，这将是致命的。
&&&&对于如今的强大硬件，缺点1尚可接受，但是循环引用导致内存泄露，注定python还将引入新的回收机制。
上面说到python里回收机制是以引用计数为主，标记-清除和分代收集两种机制为辅。
1、标记-清除机制
标记-清除机制，顾名思义，首先标记对象（垃圾检测），然后清除垃圾（垃圾回收）。如图：
首先初始所有对象标记为白色，并确定根节点对象（这些对象是不会被删除），标记它们为黑色（表示对象有效）。将有效对象引用的对象标记为灰色（表示对象可达，但它们所引用的对象还没检查），检查完灰色对象引用的对象后，将灰色标记为黑色。重复直到不存在灰色节点为止。最后白色结点都是需要清除的对象。
2、回收对象的组织
这里所采用的高级机制作为引用计数的辅助机制，用于解决产生的循环引用问题。而循环引用只会出现在&内部存在可以对其他对象引用的对象&，比如：list，class等。
为了要将这些回收对象组织起来，需要建立一个链表。自然，每个被收集的对象内就需要多提供一些信息，下面代码是回收对象里必然出现的。
1 /* GC information is stored BEFORE the object structure. */
2 typedef union _gc_head {
union _gc_head *gc_
union _gc_head *gc_
Py_ssize_t gc_
long double
/* force worst-case alignment */
9 } PyGC_H
一个对象的实际结构如图所示：
通过PyGC_Head的指针将每个回收对象连接起来，形成了一个链表，也就是在1里提到的初始化的所有对象。
3、分代技术
分代技术是一种典型的以空间换时间的技术，这也正是java里的关键技术。这种思想简单点说就是：对象存在时间越长，越可能不是垃圾，应该越少去收集。
这样的思想，可以减少标记-清除机制所带来的额外操作。分代就是将回收对象分成数个代，每个代就是一个链表（集合），代进行标记-清除的时间与代内对象
存活时间成正比例关系
1 /*** Global GC state ***/
3 struct gc_generation {
int /* collection threshold */
int /* count of allocations or collections of younger
generations */
8 };//每个代的结构
10 #define NUM_GENERATIONS 3//代的个数
11 #define GEN_HEAD(n) (&generations[n].head)
13 /* linked lists of container objects */
14 static struct gc_generation generations[NUM_GENERATIONS] = {
/* PyGC_Head,
threshold,
{{{GEN_HEAD(0), GEN_HEAD(0), 0}},
{{{GEN_HEAD(1), GEN_HEAD(1), 0}},
{{{GEN_HEAD(2), GEN_HEAD(2), 0}},
21 PyGC_Head *_PyGC_generation0 = GEN_HEAD(0);
从上面代码可以看出python里一共有三代，每个代的threshold值表示该代最多容纳对象的个数。默认情况下，当0代超过700,或1，2代超过10，垃圾回收机制将触发。
0代触发将清理所有三代，1代触发会清理1,2代，2代触发后只会清理自己。
这篇算是一个完整的收集流程：链表建立，确定根节点，垃圾标记，垃圾回收~
1、链表建立
&&& 首先，里在分代技术说过：0代触发将清理所有三代，1代触发会清理1,2代，2代触发后只会清理自己。在清理0代时，会将三个链表（代）链接起来，清理1代的时，会链接1,2两代。在后面三步，都是针对的这个建立之后的链表。
2、确定根节点
&&& 图1为一个例子。list1与list2循环引用，list3与list4循环引用。a是一个外部引用。
对于这样一个链表，我们如何得出根节点呢。python里是在引用计数的基础上又提出一个有效引用计数的概念。顾名思义，有效引用计数就是去除循环引用后的计数。
下面是计算有效引用计数的相关代码：
1 /* Set all gc_refs = ob_refcnt.
After this, gc_refs is & 0 for all objects
* in containers, and is GC_REACHABLE for all tracked gc objects not in
* containers.
5 static void
6 update_refs(PyGC_Head *containers)
PyGC_Head *gc = containers-&gc.gc_
for (; gc != gc = gc-&gc.gc_next) {
assert(gc-&gc.gc_refs == GC_REACHABLE);
gc-&gc.gc_refs = Py_REFCNT(FROM_GC(gc));
assert(gc-&gc.gc_refs != 0);
16 /* A traversal callback for subtract_refs. */
17 static int
18 visit_decref(PyObject *op, void *data)
assert(op != NULL);
if (PyObject_IS_GC(op)) {
PyGC_Head *gc = AS_GC(op);
/* We're only interested in gc_refs for objects in the
* generation being collected, which can be recognized
* because only they have positive gc_refs.
assert(gc-&gc.gc_refs != 0); /* else refcount was too small */
if (gc-&gc.gc_refs & 0)
gc-&gc.gc_refs--;
34 /* Subtract internal references from gc_refs.
After this, gc_refs is &= 0
* for all objects in containers, and is GC_REACHABLE for all tracked gc
* objects not in containers.
The ones with gc_refs & 0 are directly
* reachable from outside containers, and so can't be collected.
39 static void
40 subtract_refs(PyGC_Head *containers)
PyGC_Head *gc = containers-&gc.gc_
for (; gc != gc=gc-&gc.gc_next) {
traverse = Py_TYPE(FROM_GC(gc))-&tp_
(void) traverse(FROM_GC(gc),
(visitproc)visit_decref,
update_refs函数里建立了一个引用的副本。
visit_decref函数对引用的副本减1，subtract_refs函数里traverse的作用是遍历对象里的每一个引用，执行visit_decref操作。
最后，链表内引用计数副本非0的对象，就是根节点了。
1、为什么要建立引用副本？
答：这个过程是寻找根节点的过程，在这个时候修改计数不合适。subtract_refs会对对象的引用对象执行visit_decref操作。如果链表内对象引用了链表外对象，那么链表外对象计数会减1，显然，很有可能这个对象会被回收，而回收机制里根本不应该对非回收对象处理。
2、traverse的疑问（未解决）？
答：一开始，有个疑问。上面例子里，subtract_refs函数中处理完list1结果应该如下：
然后gc指向list2，此时list2的副本（为0）不会减少，但是list2对list1还是存在实际上的引用，那么list1副本会减1吗？显然，如果减1就出问题了。
所以list1为0时，traverse根本不会再去处理list1这些引用（或者说，list2对list1名义上不存在引用了）。
此时，又有一个问题，如果存在一个外部对象b，对list2引用，subtract_refs函数中处理完list1后，如下图：
当subtract_refs函数中遍历到list2时，list2的副本还会减1吗？显然traverse的作用还是没有理解。
3、垃圾标记
&& 接下来，python建立两条链表，一条存放根节点，以及根节点的引用对象。另外一条存放unreachable对象。
标记的方法就是里的标记思路，代码如下：
1 /* A traversal callback for move_unreachable. */
2 static int
3 visit_reachable(PyObject *op, PyGC_Head *reachable)
if (PyObject_IS_GC(op)) {
PyGC_Head *gc = AS_GC(op);
const Py_ssize_t gc_refs = gc-&gc.gc_
if (gc_refs == 0) {
/* This is in move_unreachable's 'young' list, but
* the traversal hasn't yet gotten to it.
* we need to do is tell move_unreachable that it's
* reachable.
gc-&gc.gc_refs = 1;
else if (gc_refs == GC_TENTATIVELY_UNREACHABLE) {
/* This had gc_refs = 0 when move_unreachable got
* to it, but turns out it's reachable after all.
* Move it back to move_unreachable's 'young' list,
* and move_unreachable will eventually get to it
gc_list_move(gc, reachable);
gc-&gc.gc_refs = 1;
/* Else there's nothing to do.
* If gc_refs & 0, it must be in move_unreachable's 'young'
* list, and move_unreachable will eventually get to it.
* If gc_refs == GC_REACHABLE, it's either in some other
* generation so we don't care about it, or move_unreachable
* already dealt with it.
* If gc_refs == GC_UNTRACKED, it must be ignored.
assert(gc_refs & 0
|| gc_refs == GC_REACHABLE
|| gc_refs == GC_UNTRACKED);
44 /* Move the unreachable objects from young to unreachable.
After this,
* all objects in young have gc_refs = GC_REACHABLE, and all objects in
* unreachable have gc_refs = GC_TENTATIVELY_UNREACHABLE.
All tracked
* gc objects not in young or unreachable still have gc_refs = GC_REACHABLE.
* All objects in young after this are directly or indirectly reachable
* from outsid and all objects in unreachable are
52 static void
53 move_unreachable(PyGC_Head *young, PyGC_Head *unreachable)
PyGC_Head *gc = young-&gc.gc_
/* Invariants:
all objects "to the left" of us in young have gc_refs
* = GC_REACHABLE, and are indeed reachable (directly or indirectly)
* from outside the young list as it was at entry.
All other objects
* from the original young "to the left" of us are in unreachable now,
* and have gc_refs = GC_TENTATIVELY_UNREACHABLE.
All objects to the
* left of us in 'young' now have been scanned, and no objects here
* or to the right have been scanned yet.
while (gc != young) {
PyGC_Head *
if (gc-&gc.gc_refs) {
/* gc is definitely reachable from outside the
* original 'young'.
Mark it as such, and traverse
* its pointers to find any other objects that may
* be directly reachable from it.
Note that the
* call to tp_traverse may append objects to young,
* so we have to wait until it returns to determine
* the next object to visit.
PyObject *op = FROM_GC(gc);
traverseproc traverse = Py_TYPE(op)-&tp_
assert(gc-&gc.gc_refs & 0);
gc-&gc.gc_refs = GC_REACHABLE;
(void) traverse(op,
(visitproc)visit_reachable,
(void *)young);
next = gc-&gc.gc_
/* This *may* be unreachable.
To make progress,
* assume it is.
gc isn't directly reachable from
* any object we've already traversed, but may be
* reachable from an object we haven't gotten to yet.
* visit_reachable will eventually move gc back into
* young if that's so, and we'll see it again.
next = gc-&gc.gc_
gc_list_move(gc, unreachable);
gc-&gc.gc_refs = GC_TENTATIVELY_UNREACHABLE;
标记之后，链表如上图。
4、垃圾回收
回收的过程，就是销毁不可达链表内对象。下面代码就是list的清除方法：
1 /* Methods */
3 static void
4 list_dealloc(PyListObject *op)
PyObject_GC_UnTrack(op);
Py_TRASHCAN_SAFE_BEGIN(op)
if (op-&ob_item != NULL) {
/* Do it backwards, for Christian Tismer.
There's a simple test case where somehow this reduces
thrashing when a *very* large list is created and
immediately deleted. */
i = Py_SIZE(op);
while (--i &= 0) {
Py_XDECREF(op-&ob_item[i]);
PyMem_FREE(op-&ob_item);
if (numfree & PyList_MAXFREELIST && PyList_CheckExact(op))
free_list[numfree++] =
Py_TYPE(op)-&tp_free((PyObject *)op);
Py_TRASHCAN_SAFE_END(op)
转自：https://my.oschina.net/hebianxizao/blog/59896
阅读(...) 评论()理解Python垃圾回收机制
转载 &更新时间：日 23:40:43 & 投稿：lijiao
这篇文章主要为大家详细介绍了Python垃圾回收机制，Python中的垃圾回收以引用计数为主，分代收集为辅，想要深入理解Python垃圾回收机制，请阅读下文
一.垃圾回收机制
Python中的垃圾回收是以引用计数为主，分代收集为辅。引用计数的缺陷是循环引用的问题。
在Python中，如果一个对象的引用数为0，Python虚拟机就会回收这个对象的内存。
#encoding=utf-8
__author__ = ''
class ClassA():
def __init__(self):
print 'object born,id:%s'%str(hex(id(self)))
def __del__(self):
print 'object del,id:%s'%str(hex(id(self)))
while True:
c1=ClassA()
执行f1()会循环输出这样的结果，而且进程占用的内存基本不会变动
object born,id:0x237cf58
object del,id:0x237cf58
c1=ClassA()会创建一个对象，放在0x237cf58内存中，c1变量指向这个内存，这时候这个内存的引用计数是1
del c1后，c1变量不再指向0x237cf58内存，所以这块内存的引用计数减一，等于0，所以就销毁了这个对象，然后释放内存。
1、导致引用计数+1的情况
对象被创建，例如a=23
对象被引用，例如b=a
对象被作为参数，传入到一个函数中，例如func(a)
对象作为一个元素，存储在容器中，例如list1=[a,a]
2、导致引用计数-1的情况
对象的别名被显式销毁，例如del a
对象的别名被赋予新的对象，例如a=24
一个对象离开它的作用域，例如f函数执行完毕时，func函数中的局部变量（全局变量不会）
对象所在的容器被销毁，或从容器中删除对象
def func(c,d):
print 'in func function', sys.getrefcount(c) - 1
print 'init', sys.getrefcount(11) - 1
print 'after a=11', sys.getrefcount(11) - 1
print 'after b=1', sys.getrefcount(11) - 1
print 'after func(a)', sys.getrefcount(11) - 1
list1 = [a, 12, 14]
print 'after list1=[a,12,14]', sys.getrefcount(11) - 1
print 'after a=12', sys.getrefcount(11) - 1
print 'after del a', sys.getrefcount(11) - 1
print 'after del b', sys.getrefcount(11) - 1
# list1.pop(0)
# print 'after pop list1',sys.getrefcount(11)-1
print 'after del list1', sys.getrefcount(11) - 1
after a=11 25
after b=1 26
in func function 28
after func(a) 26
after list1=[a,12,14] 27
after a=12 26
after del a 26
after del b 25
after del list1 24
问题：为什么调用函数会令引用计数+2
3、查看一个对象的引用计数
sys.getrefcount(a)可以查看a对象的引用计数，但是比正常计数大1，因为调用函数的时候传入a，这会让a的引用计数+1
二.循环引用导致内存泄露
while True:
c1=ClassA()
c2=ClassA()
执行f2()，进程占用的内存会不断增大。
object born,id:0x237cf30
object born,id:0x237cf58
创建了c1，c2后，0x237cf30（c1对应的内存，记为内存1）,0x237cf58（c2对应的内存，记为内存2）这两块内存的引用计数都是1，执行c1.t=c2和c2.t=c1后，这两块内存的引用计数变成2.
在del c1后，内存1的对象的引用计数变为1，由于不是为0，所以内存1的对象不会被销毁，所以内存2的对象的引用数依然是2，在del c2后，同理，内存1的对象，内存2的对象的引用数都是1。
虽然它们两个的对象都是可以被销毁的，但是由于循环引用，导致垃圾回收器都不会回收它们，所以就会导致内存泄露。
三.垃圾回收
# print gc.collect()
c1=ClassA()
c2=ClassA()
print gc.garbage
print gc.collect() #显式执行垃圾回收
print gc.garbage
time.sleep(10)
if __name__ == '__main__':
gc.set_debug(gc.DEBUG_LEAK) #设置gc模块的日志
gc: uncollectable &ClassA instance at &
gc: uncollectable &ClassA instance at &
gc: uncollectable &dict &
gc: uncollectable &dict 02301ED0&
object born,id:0x230e918
object born,id:0x230e940
垃圾回收后的对象会放在gc.garbage列表里面
gc.collect()会返回不可达的对象数目，4等于两个对象以及它们对应的dict
有三种情况会触发垃圾回收：
1.调用gc.collect(),
2.当gc模块的计数器达到阀值的时候。
3.程序退出的时候
四.gc模块常用功能解析
gc模块提供一个接口给开发者设置垃圾回收的选项。上面说到，采用引用计数的方法管理内存的一个缺陷是循环引用，而gc模块的一个主要功能就是解决循环引用的问题。
常用函数：
1、gc.set_debug(flags)
设置gc的debug日志，一般设置为gc.DEBUG_LEAK
2、gc.collect([generation])
显式进行垃圾回收，可以输入参数，0代表只检查第一代的对象，1代表检查一，二代的对象，2代表检查一，二，三代的对象，如果不传参数，执行一个full collection，也就是等于传2。
返回不可达（unreachable objects）对象的数目
3、gc.set_threshold(threshold0[, threshold1[, threshold2])
设置自动执行垃圾回收的频率。
4、gc.get_count()
获取当前自动执行垃圾回收的计数器，返回一个长度为3的列表
5、gc模块的自动垃圾回收机制
必须要import gc模块，并且is_enable()=True才会启动自动垃圾回收。
这个机制的主要作用就是发现并处理不可达的垃圾对象。
垃圾回收=垃圾检查+垃圾回收
在Python中，采用分代收集的方法。把对象分为三代，一开始，对象在创建的时候，放在一代中，如果在一次一代的垃圾检查中，改对象存活下来，就会被放到二代中，同理在一次二代的垃圾检查中，该对象存活下来，就会被放到三代中。
gc模块里面会有一个长度为3的列表的计数器，可以通过gc.get_count()获取。
例如(488,3,0)，其中488是指距离上一次一代垃圾检查，Python分配内存的数目减去释放内存的数目，注意是内存分配，而不是引用计数的增加。例如：
print gc.get_count() # (590, 8, 0)
a = ClassA()
print gc.get_count() # (591, 8, 0)
print gc.get_count() # (590, 8, 0)
3是指距离上一次二代垃圾检查，一代垃圾检查的次数，同理，0是指距离上一次三代垃圾检查，二代垃圾检查的次数。
gc模快有一个自动垃圾回收的阀值，即通过gc.get_threshold函数获取到的长度为3的元组，例如(700,10,10)
每一次计数器的增加，gc模块就会检查增加后的计数是否达到阀值的数目，如果是，就会执行对应的代数的垃圾检查，然后重置计数器
例如，假设阀值是(700,10,10)：
当计数器从(699,3,0)增加到(700,3,0)，gc模块就会执行gc.collect(0),即检查一代对象的垃圾，并重置计数器为(0,4,0)
当计数器从(699,9,0)增加到(700,9,0)，gc模块就会执行gc.collect(1),即检查一、二代对象的垃圾，并重置计数器为(0,0,1)
当计数器从(699,9,9)增加到(700,9,9)，gc模块就会执行gc.collect(2),即检查一、二、三代对象的垃圾，并重置计数器为(0,0,0)
如果循环引用中，两个对象都定义了__del__方法，gc模块不会销毁这些不可达对象，因为gc模块不知道应该先调用哪个对象的__del__方法，所以为了安全起见，gc模块会把对象放到gc.garbage中，但是不会销毁对象。
项目中避免循环引用
引入gc模块，启动gc模块的自动清理循环引用的对象机制
由于分代收集，所以把需要长期使用的变量集中管理，并尽快移到二代以后，减少GC检查时的消耗
gc模块唯一处理不了的是循环引用的类都有__del__方法，所以项目中要避免定义__del__方法，如果一定要使用该方法，同时导致了循环引用，需要代码显式调用gc.garbage里面的对象的__del__来打破僵局
以上就是本文的全部内容。希望对大家的学习有所帮助。
您可能感兴趣的文章:
大家感兴趣的内容
12345678910
最近更新的内容
常用在线小工具