Python：1996 年就有人试过：Greg Stein 的 free threading 补丁让单线程慢 2 倍

一、引子：一份被遗忘的 1996 年补丁

在 Python 社区关于"移除 GIL"的讨论中，PEP 703 常被视为起点。但把时间轴拉长，会发现这场博弈的起点远早于此。1996 年，Greg Stein 在 CPython 邮件列表与补丁系统中提交了一份尝试移除 GIL 的实现，其核心思路是把解释器内部原本由单一全局锁保护的共享状态，拆分为多个更细粒度的锁。补丁并未被 Guido van Rossum 接受，理由之一正是性能：单线程场景下性能回退约 2 倍。

这个数字在今天看来依然刺眼。它揭示了一个被反复验证的工程规律：任何为并发安全而引入的同步机制，都会在单线程路径上留下可测量的开销。本文评述：把这份补丁简单归类为"失败尝试"是片面的，它更像一份早期的"代价清单"，提前标注了后续所有 free threading 方案必须面对的取舍项。

需要说明的是，1996 年的补丁细节在公开邮件列表存档中并不完整，本文对其技术描述基于 CPython 历史讨论与后续文献的交叉印证，具体实现细节以原始存档为准。

二、GIL 到底是什么：从 CPython 内存模型说起

2.1 GIL 不是"Python 的锁"，而是 CPython 的实现选择

GIL（Global Interpreter Lock）是 CPython 解释器中的一把互斥锁，它保证同一时刻只有一个线程在执行 Python 字节码。需要强调：GIL 并非 Python 语言规范的一部分，而是 CPython 这一具体实现的产物。Jython、IronPython 等实现从未使用 GIL，PyPy 则长期沿用类似机制。

GIL 存在的根本原因，是 CPython 的内存管理依赖引用计数（reference counting）。每次对象引用增减都需要修改引用计数字段，若允许多线程并发修改，就必须对这些字段加锁。与其为每个对象加锁，CPython 选择了一把全局锁，用最简单的方式换取内存安全。本文评述：GIL 的本质是"用并发度换实现复杂度"，它是一笔交易，而非一个缺陷。

2.2 引用计数与 GIL 的耦合关系

理解 free threading 的难点，必须先理解引用计数与 GIL 的耦合。CPython 中，Py_INCREF 与 Py_DECREF 是最高频的操作之一。在 GIL 保护下，这些操作无需原子指令；一旦移除 GIL，每个引用计数操作都必须变成原子操作，成本随之上升。

这张表是全文的分析骨架：GIL 的移除，本质上是把"全局串行"的成本，重新分配到每一次对象操作上。1996 年的 2 倍回退，正是这种成本再分配在当时的硬件与编译器条件下的极端表现。

三、Greg Stein 补丁的技术解剖与 2 倍回退归因

3.1 补丁的核心思路

Greg Stein 的方案并非"无锁"，而是"多锁"。他把原本由 GIL 统一保护的若干解释器状态，拆分为多个独立锁：对象分配器一把、模块字典一把、引用计数相关结构若干把。线程在操作不同结构时，理论上可以并行。

本文评述：这一思路与后来的"细粒度锁"（fine-grained locking）方向一致，但在 1996 年的硬件条件下，锁的获取与释放本身就是昂贵操作。当时主流 CPU 的原子指令延迟远高于今天，锁竞争与缓存行弹跳（cache line bouncing）带来的开销被进一步放大。

3.2 2 倍回退的可能归因

需要谨慎：1996 年的原始基准数据在公开资料中并不完整，以下归因基于对当时技术条件的推理，属于分析性判断而非实测复现。

1. 锁操作开销：每次对象操作都可能触发锁获取，单线程下这些锁永远无竞争，却仍需付出原子指令成本。
2. 缓存局部性下降：细粒度锁分散在内存各处，破坏了原本紧凑的数据布局。
3. 编译器优化受限：原子操作与内存屏障会阻止编译器做指令重排与寄存器分配优化。
4. 缺乏现代同步原语：偏向锁、RCU、延迟引用计数等机制在当时尚未成熟或未被引入。

这四点归因，恰好构成了后续三十年 free threading 研究要逐一攻克的问题清单。本文评述：1996 年的补丁之所以重要，不在于它成功与否，而在于它用一次实测，把"移除 GIL 的代价"从抽象担忧变成了具体数字。

四、三十年间的失败与尝试：从 Gilectomy 到 PEP 703

4.1 Gilectomy：一次系统性的再尝试

2016 年前后，Larry Hastings 发起了 Gilectomy 项目，目标同样是移除 GIL。该项目引入了细粒度锁与延迟引用计数等机制，并在 PyCon 等场合报告了阶段性结果。其结论与 1996 年补丁形成呼应：单线程性能出现明显回退，多线程扩展性提升有限。

本文评述：Gilectomy 的价值在于它把问题从"能不能做"推进到"代价有多大、瓶颈在哪里"。它验证了引用计数是核心难点，也验证了单纯加锁无法同时满足单线程性能与多线程扩展性。

4.2 PEP 703：no-GIL 的工程化路线

PEP 703 由 Sam Gross 提出，其核心是让 GIL 成为可选，并通过一系列机制降低单线程回退。关键设计包括：

• 偏向引用计数（biased reference counting）：区分对象"拥有者线程"与"其他线程"，拥有者线程的引用计数操作无需原子指令。
• 延迟引用计数（deferred reference counting）：对某些临时引用延迟处理，减少原子操作频率。
• 不可变对象免锁：对字符串、元组等不可变对象，读取路径无需加锁。
• 每对象锁与全局停止世界（stop-the-world）：在必要时短暂暂停所有线程以完成安全操作。

PEP 703 在 Python 3.13 中以实验性特性形式落地，通过 --disable-gil 构建选项启用。本文评述：PEP 703 的工程意义在于，它把 1996 年补丁中"一刀切"的锁替换，升级为分层的、按对象状态自适应的同步策略。

4.3 PEP 779：可选 GIL 的折中

PEP 779 进一步提出，GIL 应当成为构建期可选、运行期可切换的配置，而非全局默认。这一方向承认了一个现实：并非所有工作负载都能从 free threading 中获益，单线程密集场景可能更愿意保留 GIL。

本文评述：从 1996 年的"移除"到 2024 年的"可选"，社区的态度从理想主义转向工程务实。这条演进曲线本身，就是本文分析主线的最好注脚。

五、并发粒度—内存模型—工程代价：本文的分析主线

把三十年间的尝试放在一起看，会发现它们都在回答同一个三元问题：并发粒度要多细、内存模型要多严、工程代价能承受多少。这三者构成一个不可能三角，任何方案都只能在其中取平衡。

本文评述：这张表是全文的核心论点——free threading 的进步，不是"消灭了代价"，而是"把代价从不可接受压缩到可管理"。1996 年的 2 倍回退与 PEP 703 的小幅回退之间，隔着的是偏向锁、RCU、延迟计数等一系列机制的积累。

六、关键技术机制：偏向锁、RCU、延迟引用计数

6.1 偏向引用计数：让"拥有者"走快路径

偏向引用计数的核心假设是：大多数对象的引用增减都发生在创建它的线程上。因此，可以为每个对象记录一个"拥有者线程 ID"，拥有者线程操作引用计数时走非原子快路径，其他线程则走原子慢路径。

// 偏向引用计数的伪代码示意（非 CPython 实际源码）
void Py_INCREF_biased(PyObject *obj) {
    if (obj->owner_thread == current_thread_id()) {
        obj->refcount_local++;          // 非原子，快路径
    } else {
        atomic_fetch_add(&obj->refcount_shared, 1);  // 原子，慢路径
    }
}

本文评述：偏向引用计数本质上是把"线程局部性"这一经验规律编码进内存模型。它的有效性高度依赖工作负载的访问模式，若对象频繁跨线程传递，快路径命中率下降，收益随之缩水。

6.2 RCU：读多写少场景的利器

RCU（Read-Copy-Update）源自 Linux 内核，核心思想是让读操作完全无锁，写操作通过复制与延迟释放来保证一致性。在解释器中，模块字典、类型对象等读多写少的结构，适合采用 RCU 思路。

本文评述：RCU 的引入需要垃圾回收机制的配合——延迟释放意味着内存回收时机被推迟，这与引用计数的即时回收特性存在张力。因此 RCU 在 CPython 中更多是局部应用，而非全局替换。

6.3 延迟引用计数与停止世界

延迟引用计数把部分引用操作推迟到安全点批量处理，减少原子指令频率。当需要全局一致性时，解释器可短暂"停止世界"（stop-the-world），暂停所有线程完成关键操作。

本文评述：停止世界是一把双刃剑。它简化了正确性论证，却引入了尾延迟（tail latency）风险。对延迟敏感的服务，必须评估停止世界触发的频率与时长。

七、实测数据：free threading 性能到底如何

7.1 公开基准的解读方法

评估 free threading 性能，不能只看单一数字。pyperformance 是 CPython 官方采用的基准套件，涵盖大量真实工作负载。解读时需区分：单线程几何平均、多线程扩展比、尾延迟分布三类指标。

需要说明：不同 Python 版本、不同构建配置、不同硬件平台下的基准结果差异较大。本文不引用单一来源的绝对数值，而是给出评估方法论，读者应基于自身环境复现。

7.2 自建基准的操作步骤

1. 准备环境：分别构建启用与未启用 --disable-gil 的解释器。
2. 安装基准套件：pip install pyperformance。
3. 运行单线程基准：pyperformance run -o baseline.json。
4. 运行多线程基准：使用自定义多线程负载，记录扩展比。
5. 对比与归因：用 pyperformance compare 生成差异报告。

本文评述：基准的价值不在于得出"free threading 快或慢"的结论，而在于定位回退集中在哪些操作上。若回退主要来自引用计数密集的代码路径，说明偏向锁命中率不足；若来自锁竞争，说明并发粒度仍需调整。

八、工程迁移路径：从评估到落地的操作步骤

8.1 第一步：判断是否真的需要 free threading

并非所有项目都需要移除 GIL。若瓶颈在 I/O，asyncio 或多进程已足够；若瓶颈在 CPU 密集且可并行，free threading 才有价值。本文评述：先做瓶颈定位，再谈技术选型，是避免过度工程化的前提。

8.2 第二步：C 扩展兼容性排查

free threading 对 C 扩展的影响最大。依赖 GIL 隐式保护的扩展，在无 GIL 环境下可能出现数据竞争。排查步骤：

• 列出项目所有 C/C++ 扩展依赖。
• 检查是否使用 Py_BEGIN_ALLOW_THREADS 等 GIL 相关宏。
• 确认扩展是否声明 free threading 兼容。
• 对不兼容扩展，评估替换或隔离方案。

8.3 第三步：渐进式灰度

建议先在非关键路径启用 free threading，观察稳定性与性能，再逐步扩大范围。本文评述：把 free threading 当作一次"运行时特性开关"来管理，比当作"版本升级"更符合工程实践。

九、前沿预判：PEP 779 与多解释器并行的未来

除 free threading 外，PEP 684 引入的"每解释器 GIL"（per-interpreter GIL）是另一条并行路线。它允许不同子解释器各自持有独立 GIL，从而在进程内实现真正的并行，同时保留 GIL 带来的实现简单性。

本文评述：多解释器与 free threading 并非互斥，而是互补。前者适合隔离性强的任务，后者适合共享状态多的场景。PEP 779 的"可选 GIL"正是为这种组合留出空间。

十、结论与可操作清单

回到 1996 年那份补丁。它的 2 倍回退不是失败的证明，而是问题的精确标注。三十年后的今天，PEP 703 与 PEP 779 用偏向锁、延迟计数、可选 GIL 等机制，把这份标注逐条回应。本文评述：free threading 的最终形态，大概率不是"没有 GIL"，而是"GIL 成为可选项"。