【Hard Python】【第三章-GC】1、引用计数与内存释放机制

对于编程语言runtime来说,建立起良好运转GC机制是非常必要的,像JavaGo,其GC机制都经历了复杂的演化,当然同时也为编程语言带来了更好的性能,这也是为什么这两门语言能成为主流服务端语言的原因之一。

相对于JavaGopython的GC机制是相对简约的,其中最基础的机制之一就是引用计数。当对象生成时引用计数为1;对象被其它对象引用时引用计数增加1;对象没有被引用,又退出作用域的话,引用计数归0;引用计数归0后,对象被销毁。

我们可以通过一个例子对引用计数机制进行研究:

1
2
3
def test_ref():
a = '123456789123456789'
del a

其反编译的结果是:

1
2
3
4
5
6
8           0 LOAD_CONST               1 ('123456789123456789')
2 STORE_FAST 0 (a)

9 4 DELETE_FAST 0 (a)
6 LOAD_CONST 0 (None)
8 RETURN_VALUE

STORE_FASTDELETE_FAST操作中,都用到了SET_LOCAL宏:

1
2
3
#define SETLOCAL(i, value)      do { PyObject *tmp = GETLOCAL(i); \
GETLOCAL(i) = value; \
Py_XDECREF(tmp); } while (0)

可以看到SET_LOCAL的操作是:将对应LOCAL位置的旧值拷贝到tmp指针,让后将新值赋给对应LOCAL位置,最后减少旧值tmp指针的引用计数

对于DELETE_FAST操作,SETLOCALvalue参数是NULL,这样对应LOCAL位置指针被赋值为NULL,旧值减少引用计数,这样就触发后续一系列操作了。

当调用Py_XDECREF时,实际执行了如下的操作:

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 inline void _Py_XDECREF(PyObject *op)
{
if (op != NULL) {
Py_DECREF(op);
}
}

#define Py_XDECREF(op) _Py_XDECREF(_PyObject_CAST(op))

define Py_DECREF(op) _Py_DECREF(__FILE__, __LINE__, _PyObject_CAST(op))

static inline void _Py_DECREF(const char *filename, int lineno, PyObject *op)
{
#ifdef Py_REF_DEBUG
_Py_RefTotal--;
#endif
if (--op->ob_refcnt != 0) {
#ifdef Py_REF_DEBUG
if (op->ob_refcnt < 0) {
_Py_NegativeRefcount(filename, lineno, op);
}
#endif
}
else {
_Py_Dealloc(op);
}
#endif
}

void
_Py_Dealloc(PyObject *op)
{
destructor dealloc = Py_TYPE(op)->tp_dealloc;
#ifdef Py_TRACE_REFS
_Py_ForgetReference(op);
#endif
(*dealloc)(op);
}

可以看到,如果对象内部的ob_refcnt引用计数归0,就会触发_Py_Dealloc逻辑,清空给对象分配的内存。

针对test_ref的例子,会调用py3的字符串析构逻辑,也就是unicodedealloc逻辑:

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
static void
unicode_dealloc(PyObject *unicode)
{
switch (PyUnicode_CHECK_INTERNED(unicode)) {
case SSTATE_NOT_INTERNED:
break;

case SSTATE_INTERNED_MORTAL:
{
struct _Py_unicode_state *state = get_unicode_state();
assert(Py_REFCNT(unicode) == 0);
Py_SET_REFCNT(unicode, 3);
if (PyDict_DelItem(state->interned, unicode) != 0) {
_PyErr_WriteUnraisableMsg("deletion of interned string failed",
NULL);
}
assert(Py_REFCNT(unicode) == 1);
Py_SET_REFCNT(unicode, 0);
break;
}

case SSTATE_INTERNED_IMMORTAL:
_PyObject_ASSERT_FAILED_MSG(unicode, "Immortal interned string died");
break;

default:
Py_UNREACHABLE();
}

if (_PyUnicode_HAS_WSTR_MEMORY(unicode)) {
PyObject_Free(_PyUnicode_WSTR(unicode));
}
if (_PyUnicode_HAS_UTF8_MEMORY(unicode)) {
PyObject_Free(_PyUnicode_UTF8(unicode));
}
if (!PyUnicode_IS_COMPACT(unicode) && _PyUnicode_DATA_ANY(unicode)) {
PyObject_Free(_PyUnicode_DATA_ANY(unicode));
}

Py_TYPE(unicode)->tp_free(unicode);
}

unicode的析构逻辑中,首先判断字符串是不是intern的(短字符串缓存),如果是的话会启用另外的析构逻辑,否则会跑到下面。最终调用的是Py_TYPE(unicode)->tp_free(unicode)逻辑。

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
void
PyObject_Free(void *ptr)
{
_PyObject.free(_PyObject.ctx, ptr);
}

// _PyObject.free(_PyObject.ctx, ptr)
// python_d.exe
static void
_PyMem_DebugFree(void *ctx, void *ptr)
{
_PyMem_DebugCheckGIL(__func__);
_PyMem_DebugRawFree(ctx, ptr);
}

static void
_PyMem_DebugRawFree(void *ctx, void *p)
{
/* PyMem_Free(NULL) has no effect */
if (p == NULL) {
return;
}

debug_alloc_api_t *api = (debug_alloc_api_t *)ctx;
uint8_t *q = (uint8_t *)p - 2*SST; /* address returned from malloc */
size_t nbytes;

_PyMem_DebugCheckAddress(__func__, api->api_id, p);
nbytes = read_size_t(q);
nbytes += PYMEM_DEBUG_EXTRA_BYTES;
memset(q, PYMEM_DEADBYTE, nbytes);
api->alloc.free(api->alloc.ctx, q);
}

// api->alloc.free(api->alloc.ctx, q)
static void
_PyObject_Free(void *ctx, void *p)
{
/* PyObject_Free(NULL) has no effect */
if (p == NULL) {
return;
}

if (UNLIKELY(!pymalloc_free(ctx, p))) {
/* pymalloc didn't allocate this address */
PyMem_RawFree(p);
raw_allocated_blocks--;
}
}

一路走下来,最终会调用_PyObject_Free去彻底释放这块内存,_PyObject_Free会尝试通过pymalloc_freePyMem_RawFree两种方式对对象所占内存进行释放。其中前者是采用python自带的内存管理机制,后者是采用操作系统的free方法。

这里我们需要稍微了解一下python内存管理的机制。python内部维护了不同组相同大小块的内存池,其中有几个概念:

  • arena:管理一组pool
    • 维护可用pool数量及pool总量
    • 可以有多个arena
  • pool:管理一组相同大小的block的链表
    • 正在使用中(used,非空,非满)的pool集合,会单独由usedpools数组管理
    • 申请内存时,会优先从usedpools寻找可用pool。如果block数量不够,会新增block
    • 如果没有指定大小的block,会从arena新起一个pool然后分配对应block
    • 释放对象内存时,被释放的block被转移到单独的可用block链表
  • block:一个固定大小的内存块
    • python中,有不同的固定大小,以8/16字节对齐(ALIGNMENT宏)
    • 针对不同大小的对象,分配不同大小的block

了解了这些概念,再看python对象的内存回收逻辑,就很明白了:

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
static inline int
pymalloc_free(void *ctx, void *p)
{
assert(p != NULL);

poolp pool = POOL_ADDR(p);
if (UNLIKELY(!address_in_range(p, pool))) {
return 0;
}

assert(pool->ref.count > 0); /* else it was empty */
block *lastfree = pool->freeblock;
*(block **)p = lastfree;
pool->freeblock = (block *)p;
pool->ref.count--;

if (UNLIKELY(lastfree == NULL)) {
insert_to_usedpool(pool);
return 1;
}

if (LIKELY(pool->ref.count != 0)) {
/* pool isn't empty: leave it in usedpools */
return 1;
}

insert_to_freepool(pool);
return 1;
}

最终我们可以看到,pymalloc_free主要做了以下几件事情,完成对象的内存释放:

  • 通过POOL_ADDR宏,找到指针p对应pool位置
  • 将指针p对应的内存块放到freeblock链表头部
  • 减少pool的引用数。如果归零,将pool放到对应arenafreepools
版权声明
本文为博客HiKariのTechLab原创文章,转载请标明出处,谢谢~~~