深度剖析 Python 内存管理：从引用计数到分代回收的底层逻辑

Thanks_ks

350人浏览 · 2026-07-17 19:58:32

Thanks_ks · 2026-07-17 19:58:32 发布

导语：很多 Python 开发者都有一个根深蒂固的观念："Python 有垃圾回收，我完全不需要关心内存。" 这句话在入门阶段没错，但在面对高并发服务、长时间运行的后台任务或是处理海量数据的工程时，往往会成为系统崩溃的导火索。今天，我们不写长篇大论的代码，而是潜入 CPython 解释器的底层，把 Python 的内存管理与垃圾回收机制（Garbage Collection）彻底拆解开来。

一、引子：内存管理的 "自动驾驶" 是怎么工作的？

当你写下 a = [1, 2, 3] 时，Python 在底层默默做了一系列极其复杂的工作：分配内存、创建列表对象、创建整数对象、建立引用关系……而当你不再使用这个列表时，Python 又得像一个尽职的清洁工一样，把这些内存回收掉。

在 C++ 中，这需要你手动 new 和 delete；在 Java 中，JVM 的 GC 线程会定期扫描整个堆内存。而在 Python（具体指 CPython 实现）中，内存管理采用了一套以引用计数为主，标记-清除和分代回收为辅的混合策略。

这套策略是如何运转的？我们逐层剥开它的外衣。

二、第一道防线：引用计数

Python 内存管理的绝对核心是引用计数（Reference Counting）。

2.1 什么是引用计数？

在 CPython 中，万物皆对象，而每个对象在 C 语言层面的结构体（PyObject）里，都有一个名为 ob_refcnt 的整型字段。这个字段就是该对象的 "生命线"。

规则极其简单粗暴：

增加：当对象被创建、被赋值给变量、作为参数传递、被放入容器时，引用计数 +1。
减少：当变量离开作用域、被重新赋值、被 del 显式删除、从容器中移除时，引用计数 -1。
销毁：当引用计数降为 0 时，说明没有任何地方还在使用这个对象，解释器会立刻调用该对象的析构函数（__del__），并释放其占用的内存。

2.2 为什么选择引用计数？

引用计数有一个让其他 GC 算法羡慕不来的巨大优势：实时性（Real-time）。

在 Java 或 Go 中，垃圾回收通常是由一个后台线程在某个时间点 "突然" 启动的（Stop-The-World），这会导致程序出现难以预测的停顿（STW）。而 Python 的引用计数机制下，对象一旦死亡，瞬间就被回收。内存的释放是分摊在每一次变量赋值和删除的操作中的，不会产生全局停顿。

此外，它的实现极其简单，不需要复杂的图遍历算法。

2.3 致命弱点：循环引用

引用计数虽然优雅，但它有一个致命弱点 —— 循环引用（Circular Reference）。

想象这样一个场景：

class Node:
    pass

a = Node()
b = Node()

a.next = b  # b 的引用计数 +1
b.prev = a  # a 的引用计数 +1

del a  # a 的引用计数从 2 降为 1（b.prev 还引用着它）
del b  # b 的引用计数从 2 降为 1（a.next 还引用着它）

此时，a 和 b 的引用计数都是 1。但从程序的逻辑来看，这两个对象已经没有任何外部变量可以访问到了，它们成了内存中的 "孤岛"。由于它们互相引用，计数永远无法归零，内存就这样永久泄漏了。

为了解决这个问题，Python 引入了第二道防线。

三、第二道防线：标记-清除

为了抓捕循环引用这些 "漏网之鱼"，Python 引入了标记-清除算法（Mark and Sweep）。

3.1 算法思想

标记-清除算法的逻辑非常像 "顺藤摸瓜"：

寻找根节点（Roots）：解释器从所有的 "根对象" 出发。什么是根对象？就是那些绝对不可能被回收的对象，比如当前活跃栈帧中的局部变量、全局变量、内置模块中的引用等。
标记阶段（Mark）：从根节点出发，沿着引用链向下遍历。凡是能被 "摸到" 的对象，都打上一个 "存活" 的标记。
清除阶段（Sweep）：遍历堆内存中的所有对象。没有被打上标记的对象，就是真正的 "孤岛"，直接回收。

3.2 Python 的巧妙优化

标准的标记-清除需要扫描整个堆内存中的所有对象，这在对象数量庞大时极其耗时。Python 对此做了一个极其聪明的优化：它只追踪 "可能产生循环引用" 的对象。

哪些对象可能产生循环引用？只有容器对象（如 list、dict、set、自定义类的实例）。像整数、字符串这样的不可变基础类型，是不可能引用其他对象的，自然不可能产生循环引用。

因此，Python 内部维护了一个双向链表，只有容器对象在被创建时，才会被加入到这个链表中。当标记-清除启动时，它只需要扫描这个链表里的容器对象，大大减少了扫描的范围。

四、第三道防线：分代回收

有了标记-清除，循环引用的问题解决了。但新的问题出现了：效率太低。

如果程序中有一百万个对象，每次触发 GC 都要遍历一遍，程序的运行速度会受到严重影响。为了解决效率问题，Python 引入了分代回收机制（Generational Collection）。

4.1 弱代假说

分代回收建立在一个经验主义的假说之上，即弱代假说（Weak Generational Hypothesis）：

大多数对象都是朝生夕死的（比如函数内的局部变量，函数一结束就销毁了）。
存活越久的对象，越有可能继续存活下去（比如全局配置、缓存池、单例对象）。

4.2 三代晋升机制

基于这个假说，Python 将所有需要被追踪的容器对象分成了三代（Generation 0, 1, 2）：

第 0 代（Generation 0）：所有新创建的对象都放在这里。
第 1 代（Generation 1）：在第 0 代的 GC 中存活下来的对象，会被晋升到第 1 代。
第 2 代（Generation 2）：在第 1 代的 GC 中再次存活下来的对象，会被晋升到第 2 代（也是最高代）。

4.3 触发机制与回收策略

每一代都有两个阈值：分配阈值和释放阈值。

当某一代的新分配对象数 - 释放对象数 > 分配阈值时，就会触发该代的 GC。
关键点在于：当扫描第 0 代时，只扫描第 0 代的对象；当扫描第 1 代时，会同时扫描第 0 代和第 1 代的对象。

这意味着什么？意味着那些 "老资格" 的第 2 代对象，被扫描的频率极低！这就完美契合了弱代假说，极大地提高了 GC 的效率。大多数时候，Python 只需要在新生代（第 0 代）里做快速的清理工作。

五、进阶探讨：为什么有了完美的 GC，还会内存泄漏？

理解了底层机制，我们再来看看实际工程中，为什么 Python 程序依然会发生 OOM（Out Of Memory）崩溃。请注意，以下这些情况，GC 都无能为力，因为从 GC 的视角来看，这些对象"确实还在被使用"。

5.1 陷阱一：无限增长的全局缓存

# 一个典型的全局缓存字典
_global_cache = {}

def get_user_data(user_id):
    if user_id not in _global_cache:
        _global_cache[user_id] = fetch_from_db(user_id)
    return _global_cache[user_id]

随着系统运行，_global_cache 会越来越大。由于它是全局变量（根节点），里面的所有数据引用计数永远不为 0，GC 永远不会回收它们。解法：使用 functools.lru_cache 或引入 LRU 淘汰机制的第三方缓存库。

5.2 陷阱二：闭包导致的隐性引用

def process_large_data():
    huge_data = load_gigabytes_of_data()  # 几个 G 的数据
    
    def callback():
        print("Done!")
        # 即使这里没有使用 huge_data，但在某些复杂的闭包嵌套中，
        # 外层作用域的变量可能会被意外捕获并保留。
    
    return callback

闭包会持有其外部作用域的引用。如果闭包的生命周期很长（比如被注册为某个事件监听器），那么它引用的那些本该被回收的大对象，就会一直留在内存中。

5.3 陷阱三：未清理的底层资源（C 扩展泄漏）

Python 的很多高性能库（如 NumPy、Pandas、各种数据库驱动）底层是 C/C++ 实现的。如果这些 C 扩展在分配内存后，因为异常退出或代码 Bug 没有正确释放，Python 的 GC 是完全看不到的。因为 GC 只管理 Python 对象，不管 C 语言层面 malloc 出来的内存。

5.4 陷阱四：遗留的异常追踪（Traceback）

这是一个非常隐蔽的坑。当发生异常时，Python 会生成一个 Traceback 对象，这个对象包含了发生异常时的整个栈帧信息（包括所有的局部变量）。如果你在 except 块中保存了异常对象（例如 sys.exc_info() 或 e.__traceback__），那么异常发生时的所有局部变量都会被"冻结"在内存中，直到这个异常对象被销毁。