Python：biased reference counting 原理：本线程无锁计数、跨线程原子操作的设计

1. 引言：GIL 退场后的引用计数困境

Python 的内存管理常被概括为“引用计数 + 分代 GC”，但真正让引用计数可行的，是全局解释器锁（GIL）。GIL 把并发引用计数的更新串行化，使得 Py_INCREF / Py_DECREF 无需任何原子指令即可安全执行。代价是同一时刻只有一个线程执行字节码，多核 CPU 在 CPU 密集型场景下形同虚设。

PEP 703 提出让 CPython 支持 free-threaded 构建，即移除 GIL。问题随之而来：一旦多个线程同时操作同一对象的引用计数，非原子自增自减会产生丢失更新（lost update），对象可能被提前释放或永久泄漏。最直接的方案是把引用计数全部改为原子操作，但原子指令（如 lock xadd）在 x86 上会锁定缓存行，在 ARM 上需要独占监视，单线程场景下性能回退可达数倍。

本文评述：biased reference counting 的本质不是“发明新算法”，而是对访问局部性的一次工程押注——绝大多数引用计数操作发生在对象归属线程内，因此只需为少数跨线程访问付出原子代价。这一押注是否成立，取决于真实负载的线程亲和性分布，而非理论最优。

这条主线将贯穿全文：偏置引用计数的所有设计取舍，都可以还原为“如何用局部性换原子性”。理解这一点，才能在阅读 CPython 源码时不被琐碎的位域操作淹没。

2. 引用计数基础与原子性代价

2.1 引用计数的语义模型

CPython 中每个对象头部包含 ob_refcnt 字段，记录指向该对象的强引用数量。当计数归零，对象立即被销毁并触发 tp_dealloc。这种即时回收是 Python 确定性析构（如文件句柄关闭）的基础，也是它区别于 Java/Go 追踪式 GC 的关键特性。

在 GIL 保护下，引用计数的更新是“逻辑原子”的：字节码执行期间不会被打断。但严格来说，C 层的 ob_refcnt 并非 _Atomic 类型，其原子性完全由 GIL 这一外部锁提供。这是理解后续所有改动的起点。

2.2 原子操作的硬件代价

在 x86-64 上，lock inc 会触发缓存行独占，导致其他核心的缓存副本失效。根据 Intel 优化手册，跨核原子操作延迟可达普通操作的 10–20 倍。ARM64 的 ldaxr/stlxr 独占监视机制在高竞争下还会出现重试风暴。

数据为公开微基准的典型量级，来源：Intel 64 and IA-32 Optimization Reference Manual、Arm Architecture Reference Manual，以及 Google Benchmark 社区报告（模拟整合数据，用于量级说明）。

这意味着，如果 CPython 把全部引用计数改为原子操作，单线程程序可能面临显著性能回退。Sam Gross 在 PEP 703 的早期原型中测得，全原子方案在单线程基准上回退约 30%–50%（来源：PEP 703 讨论稿与 python-dev 邮件列表，2023）。这正是 biased reference counting 要解决的核心矛盾。

3. biased reference counting 的核心设计

3.1 归属线程与偏置字段

biased reference counting 的核心思想是：为每个对象记录一个“归属线程”（owner thread），归属线程对 ob_refcnt 的增减使用普通非原子操作；非归属线程的引用则记录在独立的原子字段 ob_refcnt_split 中。对象真实引用数 = 本地计数 + 所有远程计数之和。

typedef struct _object {
    Py_ssize_t ob_refcnt;          // 归属线程本地计数（非原子）
    uint32_t   ob_refcnt_split[2]; // [0]=远程计数（原子）, [1]=归属线程ID
    PyTypeObject *ob_type;
} PyObject;

在 CPython 3.13 的 free-threaded 构建中，这一结构被进一步整合进 PyObject 头部，并通过 _PyObject_HEAD_EXTRA 等宏做条件编译。非 free-threaded 构建下，这些字段不占用额外空间。

3.2 本地计数：无锁路径

当线程 T 操作自己创建或最后一次“认领”的对象时，直接执行 ob_refcnt++。由于只有归属线程会写这个字段，不存在数据竞争，无需原子指令，也无需内存屏障。这是整个方案性能优势的来源。

笔者认为：本地计数路径的“无锁”并非绝对无同步，而是把同步成本转移到了对象归属权的判定上。判定本身需要读取归属线程ID，这个读取必须是原子的，否则会读到撕裂值。因此“无锁”更准确的说法是“单写者无竞争”。

3.3 远程计数：原子操作路径

当线程 T' 需要增加对 T 所属对象的引用时，它执行 atomic_fetch_add(&ob_refcnt_split[0], 1)。释放引用时执行原子减。远程计数永远为正或零，不会单独触发对象销毁——销毁判定由归属线程在合并后完成。

这种设计的关键收益是：远程操作只写一个独立的缓存行，不会与归属线程的本地计数产生伪共享（false sharing）。如果把本地和远程计数放在同一缓存行，归属线程的每次本地自增都会使其他核心的远程计数缓存失效，性能优势将荡然无存。CPython 通过字段对齐（padding）确保二者分离。

3.4 归属权的转移

对象归属权并非一成不变。当归属线程销毁、或对象被频繁跨线程访问时，CPython 可能触发归属权转移（ownership transfer）。转移过程需要暂停相关线程的计数操作，通常借助 stop-the-world 或原子比较交换（CAS）完成。这是实现中最复杂、也最容易出 bug 的部分。

4. 合并算法与内存序

4.1 合并的触发时机

归属线程在本地计数降到某个阈值（通常是 0 或接近 0）时，需要读取远程计数并合并，判断对象是否真正死亡。合并操作 _Py_ExplicitMergeRefcount 会原子读取 ob_refcnt_split[0]，加到本地计数上，再将远程计数清零。

// 简化示意，非 CPython 原始代码
Py_ssize_t merged = local_refcnt
                  + atomic_load_explicit(&split[0], memory_order_acquire);
if (merged == 0) {
    // 真正死亡，触发 dealloc
}

4.2 内存序的选择

合并读取远程计数必须使用 acquire 语义，确保在读取计数之前，其他线程对该对象的所有写操作都已可见。远程减引用使用 release 语义，保证对象内容修改先于计数递减对其他线程可见。这一对 acquire/release 构成了对象生命周期的同步边界。

本文评述：内存序的选择是 biased reference counting 最容易被低估的部分。很多实现者只关注“计数对不对”，却忽略了“对象内容可见性”。在弱内存模型架构（如 ARM64、RISC-V）上，错误的内存序会导致对象字段读到陈旧值，产生极难复现的 bug。

4.3 竞态窗口分析

考虑如下竞态：归属线程合并时读到远程计数为 0，正准备销毁对象；与此同时，另一线程恰好要增加远程引用。如果合并与销毁之间没有保护，就会出现 use-after-free。CPython 的解法是在合并期间对对象加“死亡标记”，任何后续远程引用操作若发现标记，会重新激活对象或触发重试。

这一机制与延迟引用计数（deferred reference counting）中的“复活”逻辑高度相似。区别在于，biased 方案的复活判定基于归属线程状态，而非全局表。

5. 与延迟引用计数、GC 的协同

5.1 延迟引用计数的历史脉络

延迟引用计数（Deferred Reference Counting, DRC）由 Deutsch 与 Bobrow 在 1976 年提出，核心思想是：来自栈或寄存器的引用不立即计入，而是延迟到栈扫描时批量处理。这减少了大量临时引用的计数开销，但引入了“对象可能被错误回收”的窗口，需要特殊处理。

PEP 703 的早期版本曾考虑 DRC，但最终选择了 biased 方案。本文评述：DRC 的延迟窗口与 Python 的确定性析构语义冲突较大，而 biased 方案保留了“归属线程即时销毁”的语义，对现有代码更友好。

5.2 与分代 GC 的接口

循环引用仍需分代 GC 处理。在 free-threaded 构建中，GC 的“停止世界”阶段需要暂停所有线程，确保遍历对象图时计数稳定。CPython 3.13 引入了 _PyThreadState_StopTheWorld 等原语，为 GC 提供全局暂停点。

GC 遍历时，对每个对象的计数读取必须合并本地与远程字段，否则可能误判对象可达性。这意味着 GC 阶段是 biased 方案中少数必须“全局一致读”的场景，也是性能瓶颈之一。

6. 工程落地：从源码到可运行实验

6.1 获取 free-threaded 构建

从 CPython 3.13 起，官方提供 free-threaded 构建选项。可通过源码编译或使用官方预编译包：

# 源码编译（Linux/macOS）
./configure --disable-gil --enable-optimizations
make -j$(nproc)

# 验证是否启用 free-threaded
python3.13t -c "import sys; print(sys._is_gil_enabled())"
# 输出 False 表示 GIL 已禁用

注意可执行文件后缀为 t（如 python3.13t），以区别于常规构建。

6.2 观测引用计数行为

可通过 sys.getrefcount 与 ctypes 直接读取对象头部，观察本地与远程计数的变化：

import sys, ctypes, threading

class Probe:
    pass

obj = Probe()
addr = id(obj)
# 读取 ob_refcnt（偏移依版本而定，仅示意）
local = ctypes.c_ssize_t.from_address(addr)
print("local refcnt:", local.value)

def worker():
    global obj
    for _ in range(1000):
        obj  # 触发跨线程引用

t = threading.Thread(target=worker)
t.start(); t.join()
print("after remote:", local.value)

上述偏移量在不同 CPython 版本中会变化，实际调试建议使用 gdb 配合 python-gdb.py 脚本，或使用 _testcapi 暴露的调试接口。

6.3 压力测试脚本

要验证跨线程计数的正确性，可构造高竞争场景：多线程反复引用/释放同一对象，配合 gc.collect() 与内存检查工具（如 valgrind、ASan）检测泄漏与 use-after-free。

import threading, gc

shared = {"data": [0] * 1000}

def churn(n):
    for _ in range(n):
        _ = shared["data"]  # 反复跨线程引用

threads = [threading.Thread(target=churn, args=(100000,)) for _ in range(8)]
for t in threads: t.start()
for t in threads: t.join()
gc.collect()
print("still alive:", shared is not None)

建议配合 PYTHONMALLOC=debug 与 -X dev 运行，开启额外一致性检查。

6.4 可操作路径清单

1. 确认 CPython 版本 ≥ 3.13，且为 free-threaded 构建。
2. 用 sys._is_gil_enabled() 验证 GIL 状态。
3. 用 threading 构造跨线程引用场景，观测计数变化。
4. 用 valgrind --tool=helgrind 或 TSan 检测数据竞争。
5. 对比 GIL 构建与 free-threaded 构建的吞吐量，记录回退比例。
6. 对关键扩展模块（C 扩展）检查是否声明 Py_MOD_GIL_NOT_USED。

7. 性能实测与数据解读

7.1 官方基准数据

根据 CPython 官方在 3.13 发布周期公布的 pyperformance 结果，free-threaded 构建在单线程基准上平均回退约 5%–10%，在多线程 CPU 密集型场景下可获得接近线性的加速（来源：CPython 3.13 What's New 与 pyperformance 官方报告，2024）。

数据来源：CPython 官方 pyperformance 汇总（2024），部分为整合数据用于趋势说明。实际数值随硬件与负载变化。

7.2 回退来源拆解

单线程回退主要来自三部分：对象头部增大导致缓存局部性下降、跨线程判定引入的额外分支、以及部分路径的原子操作。本文评述：8% 左右的单线程回退在工程上完全可接受，因为多线程收益是数量级的。真正的风险在于高竞争引用计数场景，此时原子操作成为瓶颈。

值得注意的是，若工作负载中大量对象被频繁跨线程访问，biased 方案会退化为“全原子”方案，性能优势消失。因此，评估 free-threaded 收益前，必须先测量负载的跨线程引用比例。

7.3 实测方法论

建议采用如下流程：先用 pyperf 建立基线，再用 perf stat 采集缓存未命中与原子指令计数，最后用 py-spy 采样热点。三者结合，才能定位回退是来自计数机制还是其他改动。

8. 前沿研究与替代方案对比

8.1 学术界的相关研究

引用计数的并发优化并非 Python 独有。JVM 生态的 RC 研究、Swift 的 ARC、Objective-C 的 side-table 方案都提供了对照。近年（2022–2025）较有代表性的工作包括：面向多核的“per-thread reference counting”扩展、基于 epoch 的批量回收、以及硬件辅助的计数（如 ARM MTE 与 CHERI 能力指针）。

本文评述：这些方案与 biased 的核心差异在于“计数归属粒度”。biased 以对象为粒度，per-thread 方案以线程为粒度。前者适合对象生命周期长的场景，后者适合短生命周期对象密集的场景。Python 的对象生命周期分布偏长（模块、类、缓存），因此 biased 更契合。

8.2 替代方案对比

8.3 生态适配现状

C 扩展是 free-threaded 落地的最大障碍。未声明线程安全的扩展在 free-threaded 构建下会被强制重新启用 GIL（通过 Py_MOD_GIL_USED 标记）。截至 2025 年，NumPy、Cython 等核心项目已开始适配，但大量小众扩展仍依赖 GIL。

本文评述：生态适配的进度将决定 biased RC 的实际价值。一个技术上优雅但生态无法跟进的方案，最终只能停留在实验分支。CPython 团队选择渐进式迁移（默认仍启用 GIL）是明智的。

9. 结论与预判

biased reference counting 是 CPython 在 free-threaded 道路上最关键的一步工程折中。它用“归属线程本地计数 + 跨线程原子计数”的结构，把原子操作的成本限制在真正需要的地方，从而在保持单线程性能的同时解锁多核并行。

本文的核心判断是：biased RC 的成败不取决于算法本身，而取决于负载的线程亲和性分布与生态适配速度。对于对象高度线程本地化的负载，收益显著；对于共享对象密集的负载，收益有限甚至为负。

未来 2–3 年，可预见的演进方向包括：更精细的归属权转移策略、与硬件能力指针的结合、以及针对短生命周期对象的混合计数方案。建议工程团队现在就开始测量自身负载的跨线程引用比例，为迁移决策积累数据。

参考文献与延伸资源