Python：不朽对象免计数：函数、代码、模块跳过引用计数的延迟方案

1. 引言：一次引用计数更新究竟有多贵

在 CPython 中，每当你写下一行 a = b，解释器内部至少要做一次引用计数递增；每当你离开一个作用域，又要做若干次递减。这些操作看起来微不足道，但在高频路径上，它们会累积成可观的成本。更关键的是，在多线程场景下，引用计数更新必须使用原子操作，这会触发缓存行争用，成为并发扩展性的隐形瓶颈。

本文评述：引用计数的开销并不在于单次指令的延迟，而在于它把“对象生命周期”这一本可延迟处理的语义，强行绑定到了每一次指针赋值上。对于短生命周期对象，这是必要的；但对于那些与解释器同生共死的对象，这套机制纯属冗余。

这正是“不朽对象”要解决的问题。它的核心主张非常直接：如果一个对象在解释器整个生命周期内都不会被销毁，那么它的引用计数就永远不需要归零，也就永远不需要被精确维护。我们可以把它标记为“不朽”，让所有引用计数操作对它直接短路。

PEP 683 的标题是 “Immortal Objects, Using a Fixed Refcount”，由 Eddie Elizondo 等人提出，目标是在不改变 Python 语义的前提下，消除对特定对象的引用计数维护开销。

2. CPython 对象模型与引用计数基础

2.1 PyObject 头结构

所有 CPython 对象都以 PyObject 或 PyVarObject 开头。前者包含两个字段：ob_refcnt（引用计数）和 ob_type（类型指针）。后者在此基础上追加 ob_size。

typedef struct _object {
    Py_ssize_t ob_refcnt;
    PyTypeObject *ob_type;
} PyObject;

typedef struct {
    PyObject ob_base;
    Py_ssize_t ob_size;
} PyVarObject;

在 64 位平台上，ob_refcnt 是一个 8 字节的有符号整数。这意味着每个对象至少有 16 字节的固定开销。对于小整数、短字符串这类对象，头部开销甚至超过有效载荷本身。

2.2 引用计数的增减路径

CPython 通过 Py_INCREF 和 Py_DECREF 两个宏来操作引用计数。在默认构建中，它们直接对 ob_refcnt 做加减；在启用 --with-pydebug 或特定平台时，会使用原子操作。

static inline void Py_INCREF(PyObject *op) {
    op->ob_refcnt++;
}

static inline void Py_DECREF(PyObject *op) {
    if (--op->ob_refcnt == 0) {
        _Py_Dealloc(op);
    }
}

当引用计数归零时，_Py_Dealloc 会调用对象的析构函数，释放内存。这套机制简单、确定性强，但代价是每一次赋值都要付出代价。

笔者认为：引用计数最大的工程优势是“即时回收”，最大的工程负担也是“即时维护”。不朽对象的思路，本质上是在承认“并非所有对象都需要即时回收”之后，对这套机制做的一次精准豁免。

2.3 多线程下的原子操作成本

在 GIL 存在的前提下，纯 Python 层面的并发争用被大幅削弱。但 GIL 正在被逐步移除（PEP 703，free-threading），一旦进入无 GIL 时代，引用计数的原子更新就会成为真正的热点。多个线程同时读写同一个对象的 ob_refcnt，会导致缓存行在核心之间反复弹跳。

表中数据为机制层面的定性对比，非具体基准测试数值。真实性能数据见第 6 节。

3. 不朽对象的核心思想与 PEP 683

3.1 从“延迟释放”到“永不释放”

在 PEP 683 之前，CPython 已经有一些“准不朽”对象，比如 None、True、False 以及小整数缓存中的对象。它们的引用计数被人为抬高，使得在正常使用中永远不会归零。但这只是一种“约定”，解释器仍然会为它们执行计数更新。

PEP 683 把这个约定变成了机制：引入一个特殊的引用计数哨兵值，当 ob_refcnt 等于该值时，所有增减操作都被跳过，对象被视为“不朽”。

3.2 哨兵值的选取

PEP 683 最终选用的哨兵值是 _Py_IMMORTAL_REFCNT，其定义为 UINT_MAX（在 64 位平台上为 0xFFFFFFFF）。选择这个值的原因有三：

• 足够大，正常引用不可能达到；
• 在 32 位和 64 位平台上都有明确定义；
• 便于调试时识别。

#define _Py_IMMORTAL_REFCNT UINT_MAX

static inline void Py_INCREF(PyObject *op) {
    if (op->ob_refcnt != _Py_IMMORTAL_REFCNT) {
        op->ob_refcnt++;
    }
}

本文评述：这个分支判断本身也有成本，但它是一个高度可预测的分支——对于不朽对象，分支永远走“跳过”路径，CPU 分支预测器可以轻松命中。相比原子操作，这个成本几乎可以忽略。

3.3 与 GC 的交互

CPython 的循环垃圾回收器依赖引用计数来判定对象是否可达。不朽对象的引用计数永不归零，因此 GC 不会尝试回收它们。这是符合预期的：不朽对象本就与解释器同生命周期。

需要注意的是，不朽对象仍然可能参与循环引用。如果两个不朽对象互相引用，GC 不会回收它们，因为它们本就无需回收。但如果一个不朽对象引用了一个普通对象，普通对象的引用计数会正常增加，不受影响。

4. 哪些对象适合免计数：函数、代码、模块

4.1 函数对象

函数对象是 Python 中最常见的“长寿对象”之一。一个模块级函数从定义到解释器退出，通常一直存活。每次调用函数时，解释器会创建栈帧，栈帧会引用函数对象，触发引用计数更新。在高频调用路径上，这些更新会累积。

def hot_function(x):
    return x * 2

for i in range(10_000_000):
    hot_function(i)

在这个循环中，hot_function 的引用计数会被反复增减。如果它是不朽对象，这些操作全部被跳过。

4.2 代码对象

代码对象（code 对象）是函数对象的底层载体，包含字节码、常量表、变量名表等。它们通常在模块加载时创建，之后长期存活。对代码对象的引用计数更新，同样属于冗余开销。

笔者认为：代码对象的不朽化收益，在“导入密集型”应用中尤为明显。一个大型 Python 项目在启动时可能导入数千个模块，创建数万个代码对象。如果这些对象都能免计数，启动阶段的引用计数操作量会显著下降。

4.3 模块与模块字典

模块对象本身、模块的 __dict__、以及其中存放的全局常量，都是典型的长寿对象。在 CPython 3.12 中，模块字典中的部分对象已经被标记为不朽。

5. 实现机制：哨兵值、位标记与延迟方案

5.1 哨兵值方案

哨兵值方案是最直接的实现：在 Py_INCREF 和 Py_DECREF 中加入判断，如果 ob_refcnt 等于哨兵值，则直接返回。这个方案实现简单，兼容性好，但每次操作都要多一次比较。

5.2 位标记方案

另一种思路是利用 ob_refcnt 的最高位作为“不朽标记”。这样判断只需要一次位运算，且不影响低位的计数功能。但 CPython 最终没有采用这个方案，因为它会缩小引用计数的有效范围，且与现有调试工具存在兼容性问题。

本文评述：位标记方案在理论上更优雅，但工程上更脆弱。CPython 选择哨兵值，体现的是“兼容优先、渐进演进”的一贯策略。

5.3 延迟方案：从“立即不朽”到“按需不朽”

PEP 683 的初始实现是“立即不朽”：对象在创建时就被标记为不朽。但这种方式过于激进，可能影响那些本应被回收的对象。后续讨论中出现了“延迟不朽”的思路：对象先正常计数，当引用计数达到某个阈值后，再转为不朽。

// 伪代码：延迟不朽
void maybe_immortalize(PyObject *op) {
    if (op->ob_refcnt > IMMORTAL_THRESHOLD) {
        op->ob_refcnt = _Py_IMMORTAL_REFCNT;
    }
}

这个方案的优势是自适应：只有真正长寿的对象才会被不朽化。劣势是阈值难以确定，且判断本身有成本。

6. 性能实测与数据来源

6.1 官方基准数据

根据 PEP 683 中引用的基准测试数据，在启用不朽对象后，某些工作负载的性能提升在 1% 到 5% 之间。具体数值因工作负载而异。在 pyperformance 基准套件中，部分测试项显示出稳定的小幅提升。

数据来源：PEP 683 官方文档及 CPython 3.12 发布说明。具体基准数据可在 pyperformance 仓库中复现。本文不虚构具体数值，读者应以官方发布数据为准。

6.2 无 GIL 场景下的收益

在 free-threading 构建中，不朽对象的收益更为显著。因为此时引用计数更新必须使用原子操作，而原子操作在多核争用下的成本远高于普通加减。消除这些操作，可以直接减少缓存行争用。

笔者认为：不朽对象与 free-threading 是天然搭配。前者消除了后者的一个主要瓶颈，后者则为前者提供了更大的收益空间。

6.3 模拟数据说明

本文中部分表格数据为机制层面的定性对比，属于整合分析，非具体基准测试数值。读者如需精确数据，应参考 CPython 官方基准测试结果。

7. 工程实践：迁移路径与验证方法

7.1 检查当前 Python 版本

import sys
print(sys.version_info)
# 不朽对象在 CPython 3.12 中正式引入
# 3.12 之前版本不支持

7.2 使用 sys.getrefcount 观察

import sys

def sample():
    pass

print(sys.getrefcount(sample))
# 在不朽对象启用后，某些对象的引用计数会显示为极大值
# 具体行为取决于 Python 版本和构建选项

7.3 验证不朽对象行为

import ctypes

def check_immortal(obj):
    refcnt = ctypes.c_ssize_t.from_address(id(obj)).value
    return refcnt

# 注意：直接读取 ob_refcnt 属于未定义行为
# 仅用于学习验证，生产环境不建议使用

本文评述：直接操作 ob_refcnt 是危险行为，仅建议在隔离环境中用于学习验证。生产代码应依赖官方 API。

7.4 性能对比测试方法

# 使用 pyperformance 进行基准测试
# pip install pyperformance
# pyperformance run --python=python3.12 -o result.json

# 对比不同 Python 版本的性能
# pyperformance compare result_312.json result_311.json

7.5 扩展阅读与教程链接

• PEP 683 官方文档
• Python 3.12 发布说明
• pyperformance 基准测试仓库
• CPython 内存管理相关技术演讲（YouTube）

8. 前沿研究与未来演进

8.1 free-threading 与不朽对象的协同

PEP 703 提出的 free-threading 是 CPython 近年最大的架构变革之一。在无 GIL 环境下，引用计数的原子操作成为主要瓶颈。不朽对象通过消除这些操作，为 free-threading 提供了关键支撑。

8.2 更激进的内存管理方案

学术界和工业界都在探索更激进的内存管理方案，比如基于区域的内存管理、所有权系统、以及编译期引用计数消除。不朽对象是这些探索中的一个务实步骤。

笔者认为：不朽对象不会终结引用计数，但它标志着 CPython 开始承认“一刀切”的引用计数策略需要精细化调整。未来的方向可能是更细粒度的对象生命周期分类。

8.3 对第三方扩展的影响

C 扩展开发者需要了解不朽对象的语义。如果扩展代码假设 ob_refcnt 会正常变化，可能会遇到意外行为。CPython 提供了相应的 API 来检测和处理不朽对象。

9. 结论与操作清单

不朽对象是 CPython 内存管理演进中的一个重要里程碑。它不改变 Python 语义，却能在关键路径上消除冗余开销。对于开发者而言，理解这一机制有助于写出更高效的代码，也有助于排查与引用计数相关的疑难问题。

10. 参考文献