【从1到∞精通Python】13、python的GC流程
原文链接：【Hard Python】【第三章-GC】2、python的GC流程
除了通过引用计数直接销毁对象之外，python还是拥有内在GC机制的，并且也有完整的一套流程。
如果只有通过引用计数销毁对象这种机制，那么随便构造一个循环引用就会造成内存泄漏，比如下面的代码：
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()
打印出来的结果是：
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流程的主入口，我们来看其中的代码：
// 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的代码如下：
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链表中
- 最后剩下来引用数仍然为0的
经历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的代码如下：
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链表的对象进行销毁，其代码如下：
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流程就完成了。
转载自:https://juejin.cn/post/7240427838343970871