重磅：Python 迎来多线程重大更新 no-GIL

“在 Python 中，GIL 将不复存在。对 AI 生态系统来说是巨大的胜利。”PyTorch 核心维护者 Dmytro Dzhulgakov 感慨地说道。

GIL 是什么？GIL 的全称是 Global Interpreter Lock（全局解释器锁），这不仅是 Python 的特性，而是在实现 CPython（Python 解释器）时引入的一个概念。我们可以将 GIL 理解为一个互斥锁，用于保护 Python 中的对象，防止多个线程同时执行 Python 字节码，从而确保线程安全。

然而，GIL 有一个缺点，那就是一次只有一个线程能在一个 CPU 上执行，多个线程无法映射到多个 CPU，因此 Python 无法实现真正的多线程并发，从而降低了执行效率。

现在，Python 团队已正式接受了移除 GIL 的提案，并将其作为可选模式，这对开发者来说是件好事。

这项贡献是由 Meta 公司的软件工程师 Sam Gross 完成的，他花费了四年多的时间来完成这个项目。

听到这个消息后，大家都报以热烈的掌声。深度学习三巨头之一的 Yann LeCun 发来了祝贺的消息：没有了 GIL，Python 代码现在可以自由地执行多线程了。

Python 不再有 GIL。

从 Python 中移除 GIL，将呈现出语言能力指数级增长。

关于详情，请看下文。

CPython 核心开发者 Thomas Wouters 详细介绍了无 GIL 的 Python，并展望未来。

非常感谢大家对无 GIL 提案的反馈，以及整体的积极支持。管理委员会打算接受无 GIL 提案，并在下文中与大家分享具体细节。

基本假设是：

• 长期来看（大约 5 年以上），无 GIL 构建应该是唯一的构建方式；
• 我们希望在考虑到向后兼容性时要非常小心。我们不希望出现另一个 Python 3 的情况，即所有第三方代码的更改都应仅适用于有 GIL 的构建（尽管仍需解决与旧版 Python 的向后兼容性问题）。这对于 Python 4 是行不通的。我们仍在考虑 ABI 兼容性等这两种构建的要求和其他细节，以及对向后兼容性的影响；
• 在我们完全过渡到无 GIL 设置之前，希望看到社区的支持。我们不能仅仅改变默认设置，我们希望社区能够想出支持我们的方法。我们的核心开发团队需要在新的构建模式和相关内容上获得经验。我们需要解决现有代码的线程安全性问题，并需要找出新的 C API 和 Python API。我们还需要将这些见解传达给 Python 社区的其他人，并确保我们希望进行的更改以及我们希望其他人进行的更改是可取的；
• 在我们默认设置为无 GIL 之前的任何时候，如果发现对收益太小而过于破坏性，我们希望能够改变主意。这也意味着我们撤销所有的工作，因此无 GIL 特定的代码应该在我们决定将无 GIL 设置为默认之前是可以识别的。

目前，我们认为前进的道路可以分为三个阶段：

• 短期内，我们将使无 GIL 构建成为一种实验性的构建模式，可能在 3.13（或许是 3.14）中。这是实验性的，因为我们的核心开发团队虽然支持这种构建模式，但并不指望整个社区都支持它。我们需要时间来弄清楚我们想要做什么，至少在 API 设计、打包和分发方面，以便我们能够得到社区的支持。我们还不鼓励分发者将实验性的无 GIL 构建作为默认解释器发布。
• 中期内，在我们有足够的社区支持确保无 GIL 的生产使用是可行的情况下，我们将支持无 GIL 构建，但不会默认支持，而是在某个目标日期或某个 Python 版本中成为默认方式。确切的时间取决于许多因素，例如 API 更改最终有多兼容，社区认为他们还需要做多少工作等等。我们预计这将需要至少一到两年的时间。一旦我们宣布支持，可以预期一些分发者会开始默认发布无 GIL 构建。
• 长期来看，我们希望无 GIL 成为默认选项，并移除所有 GIL 的痕迹（但不会不必要地破坏向后兼容性）。我们不想等待太久，毕竟同时存在两种常用的构建模式会给社区带来很大的负担（例如需要双倍测试资源和调试场景）。但我们也不能太仓促。我们认为这个过程将需要五年的时间。

当然，在整个过程中，我们的整个开发团队都需要实时评估进展并对时间表进行调整。

对于 GIL 可选化，你有什么想法呢？