大师兄的Python源码学习笔记(五十三）: Python的内存

大师兄的Python源码学习笔记(五十二）: Python的内存管理机制(七）
大师兄的Python源码学习笔记(五十四）: Python的内存管理机制(九）

五、Python中的垃圾收集

• 由于在Python中，内存管理的主要手段是引用计数，而标记——清除和分代收集只是为了打破循环引用而引入的补充技术。
• 这意味着Python中的垃圾收集只关注可能会产生循环引用的对象。
• 显然，像PyIntObject和PyStringObject这些对象是不会产生循环引用的，因为他们它们内部不可能持有对其它对象的引用。
• Python中的循环引用总是发生在container对象之间，比如：list、dict、class、instance等等。
• 为了达到这一点，Python必须跟踪所创建的每一个container对象，并将这些对象组织到一个集合中，才能将垃圾收集的动作限制在这些对象上。
• 实际上Python采用了一个双向链表，所有的container对象在创建之后，都会被插入到这个链表中。

1. 可收集对象链表

• 我们已经知道，任何一个Python对象都分为两部分：

• 一部分是PyObject_HEAD；
• 另一部分是对象自身的数据。

• 除此之外，为了将这个对象链入到Python内部的可收集对象链表中，成为一个可收集对象，还需要在PyObject_HEAD之前加入PyGC_Head。

Include/objimpl.h

typedef union _gc_head {
    struct {
        union _gc_head *gc_next;
        union _gc_head *gc_prev;
        Py_ssize_t gc_refs;
    } gc;
    double dummy;  /* force worst-case alignment */
} PyGC_Head;

• 所以，对于Python所创建的可收集container对象，其内存分布与我们之前所了解的内存布局不同:

Modules/gcmodule.c

PyObject *
_PyObject_GC_New(PyTypeObject *tp)
{
    PyObject *op = _PyObject_GC_Malloc(_PyObject_SIZE(tp));
    if (op != NULL)
        op = PyObject_INIT(op, tp);
    return op;
}

Modules/gcmodule.c

PyObject *
_PyObject_GC_Malloc(size_t basicsize)
{
    return _PyObject_GC_Alloc(0, basicsize);
}

Modules/gcmodule.c

#define _PyGC_REFS_UNTRACKED                    (-2)
#define GC_UNTRACKED                    _PyGC_REFS_UNTRACKED

static PyObject *
_PyObject_GC_Alloc(int use_calloc, size_t basicsize)
{
    PyObject *op;
    PyGC_Head *g;
    size_t size;
    if (basicsize > PY_SSIZE_T_MAX - sizeof(PyGC_Head))
        return PyErr_NoMemory();
    size = sizeof(PyGC_Head) + basicsize;
    if (use_calloc)
        g = (PyGC_Head *)PyObject_Calloc(1, size);
    else
        g = (PyGC_Head *)PyObject_Malloc(size);
    if (g == NULL)
        return PyErr_NoMemory();
    g->gc.gc_refs = 0;
    _PyGCHead_SET_REFS(g, GC_UNTRACKED);
    _PyRuntime.gc.generations[0].count++; /* number of allocated GC objects */
    if (_PyRuntime.gc.generations[0].count > _PyRuntime.gc.generations[0].threshold &&
        _PyRuntime.gc.enabled &&
        _PyRuntime.gc.generations[0].threshold &&
        !_PyRuntime.gc.collecting &&
        !PyErr_Occurred()) {
        _PyRuntime.gc.collecting = 1;
        collect_generations();
        _PyRuntime.gc.collecting = 0;
    }
    op = FROM_GC(g);
    return op;
}

• 从上面代码中可以看到，当Python为可收集的container对象申请内存空间时，也为PyGC_Head申请/分配了内存空间，并且在container对象之前。
• 此时，container对象的内存分布推测图如下：
  
• 从上图可以看到container对象内存分为三部分：

• PyGC_Head用于垃圾收集；
• PyObject_Head是所有对象都有的头文件；
• Container object包含container对象自身的数据。

• 在PyGC_Head部分，除了两个用于建立链表结构的双向指针外，还有一个gc_ref，这个值被初始化为GC_UNTRACKED ，它对于垃圾收集是至关重要的。
• 当垃圾收集机制运行期间，需要在一个可收集的container对象的PyGC_Head部分和PyObject_HEAD部分来回转换。
• 因此Python提供了一个对象在PyObject_HEAD和PyGC_Head两个地址之间的转换算法：

Modules/gcmodule.c

/* Get an object's GC head */
#define AS_GC(o) ((PyGC_Head *)(o)-1)

/* Get the object given the GC head */
#define FROM_GC(g) ((PyObject *)(((PyGC_Head *)g)+1))

Include/objimpl.h

#define _Py_AS_GC(o) ((PyGC_Head *)(o)-1)

• 在PyGC_Head中，出现了用于建立链表的两个指针，只有将创建的可收集container对象链接到Python内部维护的可收集对象链表中，Python的垃圾收集机制才能跟踪和处理这个container对象。
• 但实际上在创建可收集container对象之时，并没有立即将这个对象链接到链表之中。
• 这个动作是发生在创建某个container对象的最后一步，以PySliceObject为例：

Objects/sliceobject.c

PyObject *
PySlice_New(PyObject *start, PyObject *stop, PyObject *step)
{
    PySliceObject *obj;
    if (slice_cache != NULL) {
        obj = slice_cache;
        slice_cache = NULL;
        _Py_NewReference((PyObject *)obj);
    } else {
        obj = PyObject_GC_New(PySliceObject, &PySlice_Type);
        if (obj == NULL)
            return NULL;
    }

    if (step == NULL) step = Py_None;
    Py_INCREF(step);
    if (start == NULL) start = Py_None;
    Py_INCREF(start);
    if (stop == NULL) stop = Py_None;
    Py_INCREF(stop);

    obj->step = step;
    obj->start = start;
    obj->stop = stop;

    _PyObject_GC_TRACK(obj);
    return (PyObject *) obj;
}

• 在创建container对象的最后一步，Python通过_PyObject_GC_TRACK将所创建的container对象链接到Python中的可收集对象链表中：

Include/objimpl.h

/* Tell the GC to track this object.  NB: While the object is tracked the
 * collector it must be safe to call the ob_traverse method. */
#define _PyObject_GC_TRACK(o) do { \
    PyGC_Head *g = _Py_AS_GC(o); \
    if (_PyGCHead_REFS(g) != _PyGC_REFS_UNTRACKED) \
        Py_FatalError("GC object already tracked"); \
    _PyGCHead_SET_REFS(g, _PyGC_REFS_REACHABLE); \
    g->gc.gc_next = _PyGC_generation0; \
    g->gc.gc_prev = _PyGC_generation0->gc.gc_prev; \
    g->gc.gc_prev->gc.gc_next = g; \
    _PyGC_generation0->gc.gc_prev = g; \
    } while (0);

• 在define _PyObject_GC_TRACK后，我们创建的container对象已经置于Python垃圾收集机制的掌控之中了。
• 同样，Python还提供一个将container对象从链表中摘除的方法，它是define _PyObject_GC_TRACK的逆运算，这个方法在对象被销毁时调用：

Include/objimpl.h

/* Tell the GC to stop tracking this object.
 * gc_next doesn't need to be set to NULL, but doing so is a good
 * way to provoke memory errors if calling code is confused.
 */
#define _PyObject_GC_UNTRACK(o) do { \
    PyGC_Head *g = _Py_AS_GC(o); \
    assert(_PyGCHead_REFS(g) != _PyGC_REFS_UNTRACKED); \
    _PyGCHead_SET_REFS(g, _PyGC_REFS_UNTRACKED); \
    g->gc.gc_prev->gc.gc_next = g->gc.gc_next; \
    g->gc.gc_next->gc.gc_prev = g->gc.gc_prev; \
    g->gc.gc_next = NULL; \
    } while (0);

• 在Python运行的某个时刻，所建立起来的可收集对象链表如下：