Python：Gilectomy 项目的失败教训：三十年里移除 GIL 的尝试为什么都翻车

一、约束守恒：理解 GIL 的第一性原理

讨论 GIL 的文章多如牛毛，但绝大多数停留在"GIL 让多线程无法并行"这一层。这个结论没错，却无法解释一个关键事实：为什么一个被公认为性能瓶颈的设计，能在 CPython 里存活三十多年，并且至今仍是默认构建？如果 GIL 纯粹是历史包袱，那么只要有人写出正确的补丁，它早就该被删掉了。事实是，无数聪明人写过补丁，全部失败。

笔者认为，理解 GIL 的关键不在于"它做了什么坏事"，而在于"它替谁承担了成本"。这就是本文贯穿全文的分析主线——约束守恒定律：在一个成熟的运行时系统里，约束不会凭空消失，只会被转移。GIL 是一个约束的"集中承载点"，它把内存管理、扩展兼容、性能基线三方面的复杂性压缩进一把锁里。移除这把锁，等于把压缩包解压，所有被压住的复杂度会瞬间释放到系统的各个角落。

1.1 GIL 到底在保护什么

从 CPython 源码角度看，GIL 是一把全局互斥锁，任何线程执行字节码前必须持有它。官方文档（CPython Developer's Guide, 2024）明确列出了 GIL 保护的核心对象：引用计数的原子性、字节码执行的原子性、以及大量内部数据结构（如对象分配器、模块字典、类型缓存）的一致性。

这里有一个常被忽略的细节：GIL 保护的不是"Python 代码的正确性"，而是"CPython 实现内部状态的正确性"。换句话说，GIL 是解释器实现者的工具，不是语言规范的一部分。Python 语言规范从未要求存在 GIL——这是实现细节。本文评述：这一区分极其重要，它意味着"移除 GIL"在语言层面完全合法，但在实现层面要付出巨大代价，代价的大小取决于有多少实现细节依赖了这把锁。

1.2 约束守恒的数学直觉

可以用一个简化的模型来描述。设系统总约束为 C，它由三部分构成：内存管理约束 C_mem、扩展兼容约束 C_abi、性能基线约束 C_perf。GIL 方案下，这三部分被集中到一个锁 L 上，即 C ≈ f(L)。移除 L 后，约束必须重新分配到其他机制上：

C_mem → 细粒度锁 / 偏向引用计数 / 延迟回收
C_abi → 新 ABI 版本 / 兼容层 / 扩展重写
C_perf → 单线程开销上升 / 内存占用上升 / 缓存局部性下降

本文评述：这个模型的价值在于，它把"为什么失败"转化为"约束被转移到了哪里、转移成本是否可接受"。历史上每一次失败，都可以定位为某一项转移成本失控：Stein 的补丁让 C_perf 失控，Gilectomy 让 C_mem 和 C_perf 同时失控，PyPy-STM 让 C_perf 以另一种形式失控。PEP 703 之所以可能成功，是因为它选择性地接受了 C_perf 的上升（单线程约 10%–40% 开销），并用新 ABI 隔离 C_abi。

1.3 为什么"约束守恒"比"技术债"更有解释力

"技术债"是一个流行但模糊的隐喻，它暗示只要还债就能变好。约束守恒则给出更硬的判断：如果一项约束的转移成本高于它带来的收益，那么保留它就是理性选择，与"债"无关。GIL 之所以长寿，不是没人还债，而是这笔债的"再融资成本"太高。

这个视角也解释了另一个现象：为什么 Jython、IronPython 这些没有 GIL 的 Python 实现，并没有在性能上碾压 CPython？因为它们把约束转移到了宿主 VM 的锁机制和 JIT 编译复杂度上。Jython 依赖 JVM 的监视器锁，IronPython 依赖 .NET 的 CLR 线程模型——约束守恒，只是换了承载者。相关背景可参考 CPython 官方开发者指南中关于 GIL 的章节：devguide.python.org/internals/interpreter。

二、三十年攻防史：五次标志性尝试的技术复盘

要理解 Gilectomy 的失败，必须把它放回历史序列中。孤立看 Gilectomy，会以为它是一次孤立的工程失误；放进序列看，会发现它踩中了前人的每一个坑，并且新增了自己的坑。本节按时间顺序复盘五次标志性尝试，每次都用约束守恒框架标注"约束被转移到了哪里"。

2.1 1999：Greg Stein 的 free-threading 补丁

Greg Stein 在 1999 年前后提交了一组移除 GIL 的实验性补丁，思路是给解释器内部结构加细粒度锁。补丁在功能上基本可行，但在基准测试中单线程性能下降明显，且代码复杂度急剧上升。最终 Guido van Rossum 否决了该补丁，理由集中在维护成本与单线程性能回退（来源：Python 邮件列表历史存档，1999–2000）。

本文评述：Stein 补丁的失败是"约束守恒"的第一次清晰演示。它把 C_mem 从一把大锁转移到了大量细粒度锁上，结果锁竞争、死锁风险、缓存行抖动共同推高了 C_perf。更关键的是，细粒度锁让解释器代码的可维护性大幅下降——这是约束转移中被低估的"人力成本"维度。

2.2 2007–2015：PyPy 的 STM 路线

PyPy 团队走了另一条路：软件事务内存（STM）。核心思想是用事务替代锁，让运行时自动处理并发冲突。PyPy-STM 在理论上优雅，但实测中事务冲突导致的重试开销巨大，且与 JIT 的交互复杂（来源：PyPy 官方博客与相关论文，2012–2015）。该项目最终没有成为 PyPy 的默认执行模式。

本文评述：STM 路线把 C_mem 转移到了事务冲突检测与回滚机制上。问题在于，Python 程序的内存访问模式高度不规则，事务冲突率难以预测，导致性能方差极大。这提示一个规律：约束转移不仅要看平均成本，还要看方差——方差大的方案在生产环境几乎不可用。

2.3 2015–2018：Gilectomy 的激进尝试

Larry Hastings 在 2016 年 PyCon 上公布了 Gilectomy 项目，目标是"真正移除 GIL"。早期演示中，多线程场景确实获得了并行加速，但单线程性能下降到难以接受的程度。Hastings 在后续演讲中坦承，性能问题主要来自引用计数的原子化改造和对象头膨胀（来源：Larry Hastings, "Gilectomy: Removing the GIL", PyCon 2016/2017 演讲）。项目在 2018 年前后基本停止推进。

本文评述：Gilectomy 是约束守恒最惨烈的一次演示。它同时触发了 C_mem 和 C_perf 的双重失控，且没有为 C_abi 提供任何缓冲。下一节将专门解剖其技术细节。

2.4 2019–2022：子解释器与 per-interpreter GIL

PEP 554 与 PEP 684 提出了一条折中路线：保留 GIL，但让每个子解释器拥有自己的 GIL。这样多个子解释器可以在不同线程上并行。CPython 3.12 正式落地了 per-interpreter GIL（来源：PEP 684, 2022）。

本文评述：这是"约束守恒"思路的一次漂亮应用——不删除约束，而是复制约束的承载单元。代价是子解释器之间共享对象困难，跨解释器通信需要序列化。它没有解决单进程内共享内存并行的问题，但把"并行"的粒度从线程提升到了解释器。

2.5 2023 至今：PEP 703 与自由线程构建

2023 年，Sam Gross 主导的 PEP 703 被 Python 指导委员会接受，CPython 3.13 开始提供官方实验性的自由线程构建（`--disable-gil`）。与 Gilectomy 不同，PEP 703 一开始就承认单线程性能会下降，并设计了新的 C API 与 ABI 隔离机制（来源：PEP 703, 2023；CPython 3.13 What's New）。

本文评述：PEP 703 的突破不在于技术更聪明，而在于它改变了约束转移的"会计方式"——把性能损失显式定价、把 ABI 破坏显式隔离、把兼容性显式分层。这是从"偷偷转移约束"到"公开交易约束"的转变。

尝试	年份	约束转移方向	失败/结果根因
Stein free-threading	1999	细粒度锁	单线程性能与可维护性下降
PyPy-STM	2007–2015	事务内存	冲突重试开销与方差过大
Gilectomy	2015–2018	原子引用计数	单线程性能崩塌、ABI 无缓冲
per-interpreter GIL	2019–2022	约束复制	共享对象困难，非完全并行
PEP 703	2023–	显式定价 + ABI 隔离	仍在演进，性能损失已公开

三、Gilectomy 深度解剖：为什么"只删锁"必然崩盘

Gilectomy 的失败不是偶然，而是一次教科书级的"约束守恒"反面案例。它的核心错误在于：把 GIL 当成一个可以单独拆除的零件，而没有意识到 GIL 是三重约束的耦合点。本节从引用计数、对象头、缓存局部性三个技术层面解剖其崩塌机理。

3.1 引用计数的原子化陷阱

CPython 的内存管理以引用计数为主、分代 GC 为辅。在 GIL 保护下，引用计数的增减是普通的内存读写，无需原子指令。移除 GIL 后，引用计数必须变成原子操作，否则会出现竞态导致对象被提前释放或泄漏。

问题在于，原子操作的成本远高于普通读写。在 x86-64 上，一次 `lock inc` 或 `lock xadd` 需要锁定缓存行，在多核场景下会引发缓存行在核心间反复迁移（cache line bouncing）。Gilectomy 的基准测试显示，大量时间花在了原子指令的缓存一致性开销上，而非实际计算（来源：Hastings 演讲数据与相关讨论，2016–2017）。

本文评述：这是约束守恒最直观的体现——C_mem 从"一把锁"转移到了"每一次引用计数操作"。转移后，成本从"每线程一次加锁"变成"每次对象访问一次原子操作"，量级完全不同。Python 程序的对象访问极其频繁，这个转移成本根本无法摊薄。

3.2 对象头膨胀与内存占用

为了让引用计数安全，Gilectomy 尝试过多种方案，包括给对象头增加额外字段、使用偏向引用计数（biased reference counting）等。这些方案都会增加每个 Python 对象的内存开销。CPython 中一个最小对象（如小整数）本已占用约 28 字节，对象头膨胀会直接放大所有对象的内存占用。

本文评述：内存占用上升会连锁触发两个次生问题：一是缓存局部性变差，更多对象无法放进 CPU 缓存；二是 GC 压力上升，分代回收频率增加。这两个次生问题又反过来推高 C_perf。这就是约束守恒中的"耦合放大效应"——转移一项约束时，会意外激活其他约束。

3.3 单线程性能基线的崩塌

Gilectomy 最致命的问题是单线程性能。Python 的绝大多数生产负载是单线程或 IO 密集型的，单线程性能是 CPython 的生命线。Gilectomy 早期版本的单线程性能下降幅度在部分基准中达到数倍，这在生产环境中完全不可接受。

本文评述：这里有一个容易被忽视的决策逻辑——多线程并行的收益是"部分负载受益"，而单线程性能下降的代价是"全部负载受损"。在约束守恒框架下，这是一个不对称交易：收益方是少数计算密集型多线程程序，受损方是所有程序。任何理性的语言维护者都不会接受这种交易，除非收益方足够大或受损足够小。PEP 703 之所以能被接受，正是因为它把受损控制在约 10%–40%（来源：PEP 703 性能评估，2023），而不是数倍。

3.4 Gilectomy 留下的正面遗产

尽管失败，Gilectomy 并非毫无价值。它用真实数据证明了"朴素移除 GIL"不可行，迫使后续方案转向更精细的设计。PEP 703 的偏向引用计数、延迟引用计数、以及 immortal objects（不朽对象，CPython 3.12 引入）等机制，都可以看作对 Gilectomy 教训的直接回应。

本文评述：失败的工程项目的价值往往被低估。Gilectomy 的最大贡献是"证伪"——它把一条看似可行的路线彻底堵死，让社区不得不寻找更复杂的方案。在约束守恒框架下，证伪本身就是一种约束信息的获取。

四、三重约束的耦合机制：引用计数、ABI 与性能基线

前三节分别讨论了历史与 Gilectomy，本节把三重约束的耦合机制讲透。理解耦合，才能理解为什么"分而治之"的方案（如只解决引用计数）也不够。

4.1 引用计数与 ABI 的耦合

CPython 的 C 扩展 ABI 直接暴露了对象的引用计数操作。扩展模块通过 `Py_INCREF` / `Py_DECREF` 宏直接操作对象头中的 `ob_refcnt` 字段。这意味着，任何改变引用计数表示方式的方案，都会破坏现有 C 扩展的二进制兼容性。

本文评述：这是 C_mem 与 C_abi 的强耦合。Gilectomy 试图改变引用计数语义，却没有提供 ABI 兼容层，导致大量 C 扩展无法工作或行为异常。PEP 703 的应对是引入新的 C API（如 `Py_BEGIN_CRITICAL_SECTION`）并明确标记哪些 API 在自由线程下不安全。相关细节可参考 CPython 3.13 的 C API 文档：docs.python.org/3.13/c-api。

4.2 ABI 与性能基线的耦合

为了兼容现有 C 扩展，自由线程构建必须保留大量兼容路径。这些兼容路径本身会带来性能开销。例如，某些 API 在自由线程下需要加锁，而在 GIL 构建下无需加锁。同一份扩展代码，在两种构建下的性能特征可能不同。

本文评述：C_abi 与 C_perf 的耦合意味着"兼容"不是免费的。这解释了为什么 PEP 703 选择让自由线程成为一个独立的构建选项，而不是默认构建——它把兼容成本隔离在一个可选路径里，避免污染默认路径的性能。

4.3 性能基线与引用计数的耦合

引用计数的实现方式直接影响内存访问模式，进而影响缓存命中率。偏向引用计数（biased reference counting）试图通过区分"拥有者线程"与"其他线程"来减少原子操作，但增加了分支判断成本。延迟引用计数（deferred reference counting）把部分引用计数操作推迟到安全点，减少了原子操作频率，但增加了内存占用与回收延迟。

本文评述：这些方案都在做同一件事——在 C_mem、C_perf、C_abi 之间寻找新的平衡点。没有免费的午餐，只有不同的成本分配。工程决策的本质，就是选择一种自己最能承受的成本分配方式。

五、PEP 703 与 3.13 自由线程：破局逻辑与真实代价

如果说 Gilectomy 是"硬拆约束"，那么 PEP 703 就是"重新定价约束"。本节拆解 PEP 703 的破局逻辑，并给出可验证的代价评估。

5.1 破局逻辑：从隐式转移到显式交易

PEP 703 的核心创新不在单项技术，而在工程策略：它明确承认单线程性能会下降，并把自由线程作为可选构建，让用户自行权衡。这与 Gilectomy 试图"既要并行又要不损失单线程性能"的幻想形成鲜明对比。

本文评述：这是约束守恒框架下的一次"会计革命"。过去失败方案的问题是"偷偷把成本转嫁给用户"，用户发现后拒绝；PEP 703 是"公开告诉用户成本是多少，让用户自己选"。在工程决策中，透明定价往往比技术优化更能推动采纳。

5.2 关键技术机制

PEP 703 涉及多项机制，主要包括：

• 偏向引用计数：对象记录拥有者线程，拥有者线程的引用计数操作无需原子化，其他线程的操作走原子路径。
• 不朽对象（immortal objects）：对永不释放的对象（如 None、True、小整数）跳过引用计数，减少原子操作。
• 延迟引用计数：部分引用计数操作推迟到安全点批量处理。
• 临界区 API：提供 `Py_BEGIN_CRITICAL_SECTION` 等显式临界区，让扩展作者声明并发安全边界。
• 新 ABI 隔离：自由线程构建使用独立的 ABI 标记，避免与 GIL 构建混用。

本文评述：这些机制共同构成一个"约束再分配方案"。偏向引用计数把 C_mem 的成本从"所有线程"转移到"非拥有者线程"；不朽对象把部分成本直接消除；临界区 API 把 C_abi 的兼容责任部分转移给扩展作者。每一项都在做精细的成本分配。

5.3 真实代价：性能数据与来源

根据 PEP 703 与 CPython 3.13 官方文档，自由线程构建的单线程性能开销大致在 10%–40% 区间，具体取决于工作负载。多线程计算密集型负载可获得接近线性的加速。内存占用通常有上升。需要强调，这些数字随版本迭代变化，应以官方最新基准为准。

维度	GIL 构建	自由线程构建	说明
单线程性能	基线	约 -10% ~ -40%	随版本优化变化
多线程计算	无并行加速	接近线性	受临界区与锁竞争影响
C 扩展兼容	完全兼容	部分需适配	依赖新 API 与 ABI 标记
内存占用	基线	通常上升	对象头与延迟回收影响

本文评述：这张表本身就是约束守恒的"价目表"。它告诉工程团队：并行能力不是免费的，价格是单线程性能、兼容成本、内存占用。是否购买，取决于你的负载结构。关于自由线程构建的官方说明，可参考 docs.python.org/3.13/whatsnew。

5.4 与 Gilectomy 的关键差异

把 PEP 703 与 Gilectomy 并排看，差异集中在三点：一是性能损失被显式承认并量化；二是 ABI 破坏被隔离在独立构建中；三是扩展兼容责任被部分转移给扩展作者，并提供新 API。这三点恰好对应三重约束的重新分配。

本文评述：PEP 703 的成功概率高于 Gilectomy，不是因为它更"聪明"，而是因为它更"诚实"。工程史上，诚实定价的方案往往比承诺免费的方案走得更远。

六、工程迁移路径：从评估到落地的六步法

理论讲完，进入可操作部分。本节给出一个六步迁移法，适用于评估是否以及如何迁移到自由线程构建。每一步都给出具体动作与判断标准。

步骤一：负载画像

动作：采集生产环境的 CPU 使用率、线程模型、GIL 竞争指标（如 `sys._stats` 或采样 profiler）。判断标准：如果 CPU 利用率长期低于单核上限，且瓶颈在 IO，则自由线程收益有限。

步骤二：依赖审计

动作：列出所有 C 扩展依赖，检查其是否声明支持自由线程。判断标准：核心依赖（如 NumPy、数据库驱动）若无自由线程支持，迁移风险高。可参考各项目官方 issue 与发布说明。

步骤三：基准对比

动作：在 GIL 构建与自由线程构建下分别运行代表性负载，记录单线程延迟、多线程吞吐、内存占用。判断标准：多线程吞吐提升是否足以覆盖单线程延迟上升。

步骤四：临界区改造

动作：对自研 C 扩展，使用 `Py_BEGIN_CRITICAL_SECTION` 等 API 标注并发安全边界。判断标准：改造后是否通过压力测试与数据竞争检测工具（如 ThreadSanitizer）。

步骤五：灰度发布

动作：选择非核心服务先行迁移，监控错误率、延迟分布、内存增长。判断标准：错误率与延迟分布无显著恶化。

步骤六：回滚预案

动作：保留 GIL 构建的部署包，确保可在分钟级回滚。判断标准：回滚演练通过。

七、决策矩阵：什么场景该用自由线程，什么场景不该

不是所有团队都需要自由线程。本节给出一个决策矩阵，帮助快速判断。

场景	建议	理由
IO 密集型 Web 服务	暂不迁移	瓶颈在 IO，GIL 非主要矛盾
CPU 密集型数值计算	优先评估	并行收益可能显著
依赖大量未适配 C 扩展	暂不迁移	兼容风险高
自研扩展可控	可试点	改造范围可控
低延迟单线程服务	谨慎	单线程性能损失敏感
已有子解释器方案	可继续	per-interpreter GIL 已满足需求

本文评述：决策矩阵的核心逻辑仍是约束守恒——先确认你的约束瓶颈在哪里，再判断自由线程是否把约束转移到了你能承受的地方。如果你的瓶颈是 IO，那么移除 GIL 只是把约束从"锁"转移到"性能损失"，净收益为负。

八、前沿预判：GIL 之后的下一个约束在哪里

假设自由线程构建在未来几年逐步成熟，下一个约束会出现在哪里？本节给出三个方向的预判，均基于约束守恒框架推导。

8.1 数据竞争与调试复杂度

GIL 的一个隐性好处是"免费线程安全"——大量 Python 代码在 GIL 下天然无数据竞争。移除 GIL 后，这些代码可能暴露隐藏的竞态。调试并发 bug 的成本远高于调试单线程 bug，这会成为新的约束。

本文评述：这是 C_mem 转移后的次生约束。约束从"运行时锁"转移到了"开发者心智负担"。工具链（如竞争检测、确定性重放）的成熟度将决定这一约束的实际成本。

8.2 内存模型与可见性

Python 语言规范目前没有正式的内存模型。在 GIL 下这不是问题，因为锁天然提供了可见性保证。移除 GIL 后，内存可见性需要显式定义。PEP 703 引入了临界区概念，但完整的内存模型仍在讨论中。

本文评述：这是 C_abi 与 C_mem 耦合的新表现。没有正式内存模型，扩展作者难以写出可移植的并发代码。这将成为自由线程生态成熟的关键瓶颈。

8.3 生态碎片化

自由线程作为可选构建，意味着生态可能分裂为"GIL 派"与"自由线程派"。包维护者需要同时支持两种构建，测试矩阵翻倍。

本文评述：这是约束从"运行时"转移到"生态维护"的典型案例。约束守恒不仅适用于技术内部，也适用于社区协作成本。历史上 Python 2/3 分裂的教训表明，生态碎片化的代价可能远超技术收益。

九、结论与行动清单

回到本文主线：GIL 不是可以单独拆除的零件，而是引用计数、C 扩展 ABI、单线程性能基线三重约束的耦合点。三十年移除尝试的失败，本质上都是约束转移成本失控。Gilectomy 的失败在于同时触发 C_mem 与 C_perf 双重失控且无 ABI 缓冲；PEP 703 的进展在于把约束转移显式定价、分层隔离。

对工程团队的行动建议：

1. 先画像，后决策：确认 GIL 是否真的是你的瓶颈。
2. 审计依赖：核心 C 扩展的自由线程支持度决定迁移可行性。
3. 小步试点：从自研扩展可控的服务开始。
4. 保留回滚：自由线程仍是演进中的技术，回滚能力是底线。
5. 关注内存模型：它将是下一阶段的关键约束。

本文评述：GIL 的故事远未结束，但分析框架已经清晰。约束守恒定律告诉我们，不要问"能不能移除 GIL"，而要问"移除后约束去了哪里、我能不能承受"。这个问题的答案，因团队而异，因负载而异。技术决策的成熟，正体现在能否把这样的问题问清楚。