【Hard Python】【第三章-GC】2、python的GC流程

发表于 | 更新于 | 分类于 | 阅读次数：

除了通过引用计数直接销毁对象之外，python还是拥有内在GC机制的，并且也有完整的一套流程。

如果只有通过引用计数销毁对象这种机制，那么随便构造一个循环引用就会造成内存泄漏，比如下面的代码：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
def _dump_gc():
    gcobjs = gc.get_objects()
    pprint.pprint(len(gcobjs))


def test_circle():
    def _test_internal():
        _dump_gc()
        a = []
        b = []
        a.append(b)
        b.append(a)
        _dump_gc()

    _test_internal()
    _dump_gc()
    gc.collect()
    _dump_gc()

打印出来的结果是：

1
2
3
4
13707
13709
13709
13370

很显然，当退出_test_internal作用域时，gc对象的数量没有变化，这就说明在_test_internal里创建的a、b两个对象没有被立即释放掉。如果注释掉两个append行，就能看到打印结果第三行变成了13707，说明a、b在退出函数时就被销毁了。

所以首先，我们从循环引用入手，来研究一下python的gc机制（好巧不巧的是，python的gc也是专门为循环引用而设置的）。调用gc.collect触发gc之后，会跑到gc_collect_main触发完整的gc流程。gc_collect_main是python整个gc流程的主入口，我们来看其中的代码：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
// gcmodule.c
static Py_ssize_t
gc_collect_main(PyThreadState *tstate, int generation,
                Py_ssize_t *n_collected, Py_ssize_t *n_uncollectable,
                int nofail)
{
    int i;
    Py_ssize_t m = 0; /* # objects collected */
    Py_ssize_t n = 0; /* # unreachable objects that couldn't be collected */
    PyGC_Head *young; /* the generation we are examining */
    PyGC_Head *old; /* next older generation */
    PyGC_Head unreachable; /* non-problematic unreachable trash */
    PyGC_Head finalizers;  /* objects with, & reachable from, __del__ */
    PyGC_Head *gc;
    _PyTime_t t1 = 0;   /* initialize to prevent a compiler warning */
    GCState *gcstate = &tstate->interp->gc;

    /* update collection and allocation counters */
    if (generation+1 < NUM_GENERATIONS)
        gcstate->generations[generation+1].count += 1;
    for (i = 0; i <= generation; i++)
        gcstate->generations[i].count = 0;

    /* merge younger generations with one we are currently collecting */
    for (i = 0; i < generation; i++) {
        gc_list_merge(GEN_HEAD(gcstate, i), GEN_HEAD(gcstate, generation));
    }

    /* handy references */
    young = GEN_HEAD(gcstate, generation);
    if (generation < NUM_GENERATIONS-1)
        old = GEN_HEAD(gcstate, generation+1);
    else
        old = young;

    deduce_unreachable(young, &unreachable);

    untrack_tuples(young);
    /* Move reachable objects to next generation. */
    if (young != old) {
        if (generation == NUM_GENERATIONS - 2) {
            gcstate->long_lived_pending += gc_list_size(young);
        }
        gc_list_merge(young, old);
    }
    else {
        /* We only un-track dicts in full collections, to avoid quadratic
           dict build-up. See issue #14775. */
        untrack_dicts(young);
        gcstate->long_lived_pending = 0;
        gcstate->long_lived_total = gc_list_size(young);
    }

    /* All objects in unreachable are trash, but objects reachable from
     * legacy finalizers (e.g. tp_del) can't safely be deleted.
     */
    gc_list_init(&finalizers);
    // NEXT_MASK_UNREACHABLE is cleared here.
    // After move_legacy_finalizers(), unreachable is normal list.
    move_legacy_finalizers(&unreachable, &finalizers);
    /* finalizers contains the unreachable objects with a legacy finalizer;
     * unreachable objects reachable *from* those are also uncollectable,
     * and we move those into the finalizers list too.
     */
    move_legacy_finalizer_reachable(&finalizers);

    /* Clear weakrefs and invoke callbacks as necessary. */
    m += handle_weakrefs(&unreachable, old);

    validate_list(old, collecting_clear_unreachable_clear);
    validate_list(&unreachable, collecting_set_unreachable_clear);

    /* Call tp_finalize on objects which have one. */
    finalize_garbage(tstate, &unreachable);

    /* Handle any objects that may have resurrected after the call
     * to 'finalize_garbage' and continue the collection with the
     * objects that are still unreachable */
    PyGC_Head final_unreachable;
    handle_resurrected_objects(&unreachable, &final_unreachable, old);

    /* Call tp_clear on objects in the final_unreachable set.  This will cause
    * the reference cycles to be broken.  It may also cause some objects
    * in finalizers to be freed.
    */
    m += gc_list_size(&final_unreachable);
    delete_garbage(tstate, gcstate, &final_unreachable, old);

    /* Append instances in the uncollectable set to a Python
     * reachable list of garbage.  The programmer has to deal with
     * this if they insist on creating this type of structure.
     */
    handle_legacy_finalizers(tstate, gcstate, &finalizers, old);

    /* Clear free list only during the collection of the highest
     * generation */
    if (generation == NUM_GENERATIONS-1) {
        clear_freelists(tstate->interp);
    }

    if (_PyErr_Occurred(tstate)) {
        if (nofail) {
            _PyErr_Clear(tstate);
        }
        else {
            _PyErr_WriteUnraisableMsg("in garbage collection", NULL);
        }
    }

    /* Update stats */
    if (n_collected) {
        *n_collected = m;
    }
    if (n_uncollectable) {
        *n_uncollectable = n;
    }

    struct gc_generation_stats *stats = &gcstate->generation_stats[generation];
    stats->collections++;
    stats->collected += m;
    stats->uncollectable += n;

    assert(!_PyErr_Occurred(tstate));
    return n + m;
}

gc_collect_main总共执行了以下几个步骤，一个一个来说。

首先更新指定generation后的分配计数（+1），指定generation及以下的全部归0。这是因为python也自带了分代回收机制，gc.collect入参是generation，指定generation以下的全部都会被gc掉。

python的gc分代总共是3代，而gc.collect默认值是2，也表示最高一代，通俗点讲就是Full GC。每一代的对象数目如果超过特定值，就会触发自动gc。

然后做的一个事情是，将指定generation前代的和当代的所有GC_Head全部串到一个链表上，这样只需要处理这一个链表就能回收所有东西。每个python对象都会自带GC_Head，串到特定genenration的链表中，用于在GC时候被识别到。

之后做的很关键的一步是deduce_unreachable，其作用是模拟去引用的流程，探测无法从gc根对象直接达到的对象，放到单独的unreachable列表中。并且在这一步会通过遍历对象之间的引用关系并-1引用的方式，从而将对象之间的循环引用暂时归零。deduce_unreachable的代码如下：

1
2
3
4
5
6
7
8
9
10
static inline void
deduce_unreachable(PyGC_Head *base, PyGC_Head *unreachable) {
    validate_list(base, collecting_clear_unreachable_clear);
    update_refs(base);  // gc_prev is used for gc_refs
    subtract_refs(base);
    gc_list_init(unreachable);
    move_unreachable(base, unreachable);  // gc_prev is pointer again
    validate_list(base, collecting_clear_unreachable_clear);
    validate_list(unreachable, collecting_set_unreachable_set);
}

好比一个场景：总共有4个list对象，分别为l1到l4，其中l1、l2循环引用，l3、l4循环引用，l1和l2与l3跟l4之间没有关联。之后若再有一个变量a引用了l1，那么经过deduce_unreachable之后，会呈现如下的结果：

  • 在subtract_refs步骤中，l1的引用数目变成1，l2、l3、l4变成0
  • 在move_unreachable步骤中，发现l1引用数目为1，即将l1以及其引用到的所有变量标记为reachable
    • 最后剩下来引用数仍然为0的l3、l4，放到unreachable链表中

经历deduce_unreachable步骤存活下来的reachable对象，会直接被移动到下一个generation。接下来只需要考虑对unreachable的对象进行销毁了。

接下来的操作是将unreachable链表中，会处理一些C层类型定义里含有旧版tc_del方法的类型的对象，这些对象及其直接或间接引用的对象全部都会被移动到单独的finalizers链表中，而这个链表中的对象会被单独维护，无法被回收。

在以前的版本中，如果python类型定义了__del__方法，那么这些类型的对象就会移动到finalizers链表中。直到PEP442之后，__del__方法就对应了C层类型定义的另外一个tc_finalize方法了，因此包含__del__方法的类型的对象，不一定会移动到finalizers链表中，而是会在后面的步骤中触发tc_finalize逻辑。

再之后，针对剩下的unreachable对象，通过handle_weakrefs方法解除其它对象对其的弱引用。然后调用finalize_garbage销毁unreachable对象。finalize_garbage的代码如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
static void
finalize_garbage(PyThreadState *tstate, PyGC_Head *collectable)
{
    destructor finalize;
    PyGC_Head seen;
    gc_list_init(&seen);

    while (!gc_list_is_empty(collectable)) {
        PyGC_Head *gc = GC_NEXT(collectable);
        PyObject *op = FROM_GC(gc);
        gc_list_move(gc, &seen);
        if (!_PyGCHead_FINALIZED(gc) &&
                (finalize = Py_TYPE(op)->tp_finalize) != NULL) {
            _PyGCHead_SET_FINALIZED(gc);
            Py_INCREF(op);
            finalize(op);
            assert(!_PyErr_Occurred(tstate));
            Py_DECREF(op);
        }
    }
    gc_list_merge(&seen, collectable);
}

finalize_garbage实质是调用对象类型定义的tp_finalize方法析构对应的对象，并减少其引用为0从而释放对象内存。由于某些对象类型可能没有默认的tp_finalize方法，因此经过这一步骤之后，还会存留一些未销毁的对象。

针对未销毁的对象，之后会通过handle_resurrected_objects进行处理。在handle_resurrected_objects中会再一次执行deduce_unreachable模拟去引用操作，存活下来的unreachable对象就被移到下一个generation，而剩下的对象就会被移动到final_unreachable链表进行后面的销毁操作。

通过delete_garbage方法会对final_unreachable链表的对象进行销毁，其代码如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
static void
delete_garbage(PyThreadState *tstate, GCState *gcstate,
               PyGC_Head *collectable, PyGC_Head *old)
{
    assert(!_PyErr_Occurred(tstate));

    while (!gc_list_is_empty(collectable)) {
        PyGC_Head *gc = GC_NEXT(collectable);
        PyObject *op = FROM_GC(gc);

        _PyObject_ASSERT_WITH_MSG(op, Py_REFCNT(op) > 0,
                                  "refcount is too small");

        if (gcstate->debug & DEBUG_SAVEALL) {
            assert(gcstate->garbage != NULL);
            if (PyList_Append(gcstate->garbage, op) < 0) {
                _PyErr_Clear(tstate);
            }
        }
        else {
            inquiry clear;
            if ((clear = Py_TYPE(op)->tp_clear) != NULL) {
                Py_INCREF(op);
                (void) clear(op);
                if (_PyErr_Occurred(tstate)) {
                    _PyErr_WriteUnraisableMsg("in tp_clear of",
                                              (PyObject*)Py_TYPE(op));
                }
                Py_DECREF(op);
            }
        }
        if (GC_NEXT(collectable) == gc) {
            /* object is still alive, move it, it may die later */
            gc_clear_collecting(gc);
            gc_list_move(gc, old);
        }
    }
}

delete_garbage中，每一个对象都会调用其类型的tp_clear方法，减少对象引用数目为0，触发对象的销毁。

在delete_garbage之后，终于就会对先前单独拎出来的finalizers链表进行处理。finalizers链表中所有的内容都会通过handle_legacy_finalizers方法被移动到当前gcstate的garbage链表中单独维护，不会被销毁。

之后进行一些数据清理和数据统计逻辑，整个gc流程就完成了。

版权声明
本文为博客HiKariのTechLab原创文章，转载请标明出处，谢谢~~~