Python 中有一把著名的锁——全局解释器锁（Global Interpreter Lock，简写 GIL），它的作用是防止多个本地线程同时执行 Python 字节码，这会导致 Python 无法实现真正的多线程执行。（注：本文中 Python 解释器特指 CPython）

这把锁在 Python 的早期发展中具有积极的作用（单核 CPU 时代），然而，它阻碍了 Python 在多核 CPU 上的并行编程，引起了开发者们与日俱增的诟病。

GIL 影响的主要是 CPU 密集型任务，比如科学计算与数值计算任务。

在最近发布的 PEP-703 中，它概括了 GIL 对科学计算（主要是 AI/ML）造成的四类问题：

• GIL 导致许多并行化操作难以表达（影响强化学习、DeepMind、医学治疗及生物研究等领域）

• GIL 影响了 Python 库的可用性（例如 PyTorch、scikit-learn、NumPy）

• GIL 导致无法充分利用 GPU 资源（例如计算机视觉任务）

• GIL 导致难以部署 Python AI 模型（例如基于神经网络的 AI 模型）

社区中想要移除 GIL 的呼声以及尝试，此起彼伏，绵绵不绝，但这个话题一直悬而未决。

抱怨、质疑、不满、不甘、期盼等这些诸多的情绪，不是那么容易平息的。然而，从一个积重已久的庞大的项目中移除一个根基性的设计，又谈何容易？

2023 新年刚过，这个话题又一次热了起来，又一轮对 GIL 的挑战开始了。

这一次，事情似乎有了新的转机，这次也许能成功了呢？

PEP-703

PEP-703 在今年 1 月 9 日新鲜出炉，虽然它目前仍是“草案”状态未被采纳，但是这份 PEP 的意义十分重大！

（注：每个 Python 学习者都应该基本了解 PEP，建议阅读《学习Python，怎能不懂点PEP呢？》）

这个 PEP 的作者是 Sam Gross，他是 nogil 项目的作者。Python猫的老读者应该有印象，我们在 2021 年曾翻译过他与 Python 核心开发者们的一次研讨会的纪要，这份纪要里概括了 nogil 的主要设计思路，同时回答了核心开发者们最为关注的约 20 个问题。

经过一年多时间的沉淀，nogil 项目现在终于形成了正式的 PEP，这意味着它被采纳进 Python 主分支的可能性变大了一些啦！

PEP 的标题是《使 CPython 的 GIL 成为可选项》（Making the Global Interpreter Lock Optional in CPython），内容详实，正文超过 1 万字，这个体量的 PEP 绝对够得上排在所有 PEP 的前十了。

简单而言，这份提案提议给 CPython 增加一个构建时配置项--disable-gil ，作用是构建出一个线程安全的无 GIL 的解释器。

为了实现无 GIL 的解释器，Python 底层的部分设计必须作出变更，内容可以概括成四类：

• 引用计数

• 内存管理

• 容器线程安全

• 锁和原子 API

如果这份 PEP 被采纳实现的话，它会带来一个不容忽视的问题：Python 将发布两个不同版本的解释器，而第三方库也要相应地开发/维护/发布两个版本的软件包。

PEP-703 的作者也考虑到了这个问题，他提出的解决方案是与 Anaconda 一起发布无 GIL 的 Python，同时在 conda 里集中发布管理那些兼容了新 Python 的库。

考虑到 Anaconda 在科学计算与数值计算领域的强大影响力，此举既能较好地发挥 nogil Python 的用处，又能减少用户及三方库开发者面对两种发行版时的割裂感。

值得注意的是，nogil 的 Python 还有一个更大的问题，那就是会影响单线程程序的性能。

基于 Python 3.11 版本，实现了有偏见的引用计数及永生对象后，Python 单线程性能会变慢 10%。

尽管这个数值在最新的 nogil 原型版本上可以降低到 5%，但是，另外至少还有两项难以规避的性能下降点：

• 2% - 全局的自由列表（主要是元组和浮点数自由列表）

• 1.5% - 集合中每个对象的互斥锁（字典、列表、队列）

单线程的代码才是最广泛的使用场景，可以说这会影响到每一个 Python 用户。任何试图移除 GIL 的项目都不可避免要面临这项挑战。

尽管存在着以上的两大问题，但 PEP-703 还是很有可取之处的。

比如，相比于 2015 年提出的著名的 Gilectomy 项目（由 GIL ectomy 两个单词组合而成，ectomy 是一个医学上的术语“切除术”），nogil 在单线程的性能上要快得多，同时可扩展性也更好。

比如，相比于 2021 年火热的“香农计划”的作者 Eric Snow 提出的 PEP-684 方案（给每个子解释器创建 GIL），后者一方面需要实现作为前提的多个 PEP（如 PEP-554、PEP-683），另一方面需要用户处理多子解释器间共享变量的麻烦。

PEP-684

在香农计划的《Python 3.12 目标》中，PEP-554 与 PEP-684 已经囊括在内了，版本目标是充分利用 Python 的子解释器，让子解释器使用各自的 GIL，从而实现多线程的并行。

好消息是，3.12 的计划跟本文的主角  PEP-703 并不冲突。事实上，它们的很多设计细节是一致的，也就是说，这两套对于 GIL 的改造方案是可以共存的，它们相互促进，事半功倍！

香农计划有 Python 之父 Guido van Rossum 站台，还有财大气粗的微软支持着一支豪华的团队投入开发（含 Guido 和 Eric Snow），因此，多解释器多 GIL 的方案很可能会更快落地。

PEP-703 的讨论

而 PEP-703 有 PSF 首位全职开发者 Łukasz Langa 的倾力支持，社区的反响也不错，我觉得它今后落地的希望也挺大！

无论如何，这次香农计划和 PEP-703 掀起的对 GIL 的挑战，比以往所有的尝试都更猛烈，更有成功的可能，让人不由得心生欢欣之喜~~

但愿它们实现的一天不会太远吧。