Python社区变天：可去除全局解释器锁GIL，真正多线程要来了 _Python

编辑：杜伟、陈萍

这次，Python/ target=_blank class=infotextkey>Python 将不再是人们所说的伪多线程了。

「Python 中的 GIL 将不复存在，这是人工智能生态系统领域中的巨大胜利。」PyTorch 核心维护者 Dmytro Dzhulgakov 感慨道。

文章插图
GIL 是什么？GIL 的全称是 Global Interpreter Lock（全局解释器锁），它不是 Python 独有的，而是在实现 CPython（Python 解释器）时引入的一个概念。我们可以将 GIL 理解为一个互斥锁，用来保护 Python 里的对象，防止同一时刻多个线程执行 Python 的字节码，从而确保线程安全。

文章插图
图源：
https://realpython.com/python-gil/
然而，GIL 存在一个弊端，即在同一时刻只能有一个线程在一个 CPU 上执行，无法将多个线程映射到多个 CPU 上，使得 Python 并不能实现真正的多线程并发，从而降低了执行效率。
现在，Python 团队已经正式接受了删除 GIL 的这个提议，并将其设置为可选模式，可谓是利好广大开发者。
做出这一贡献的是一位来自 Meta 的名叫 Sam Gross 的软件工程师，他花费了四年多的时间才完成这一工程。
在得知这一消息后，大家纷纷叫好，深度学习三巨头之一的 Yann LeCun 发文祝贺：没有了 GIL，现在，Python 代码可以自由的执行多线程了。

文章插图
「Python 中终于没有 GIL 了！」

文章插图
「这是一个里程碑式的决定，是编码社区所热切期待的。」

文章插图
具体细节如何，我们接着看下文。
CPython 核心开发者 Thomas Wouters 撰文描述了 Python 中的无 GIL 细节，并对未来发展做了展望。
非常感谢所有人对无 GIL 提议的反馈，整体上都持积极的支持态度。指导委员会打算接受无 GIL 提议，并就以下具体细节与大家分享。
我们的基本设想是：

长期来看（大约 5 年以上），no-GIL 构建应是唯一的构建；
我们希望非常谨慎地向后兼容。我们不希望出现另一个 Python 3 的情况，所有适应 no-GIL 构建所需的任何第三方代码更改应只适用于 with-GIL 构建（尽管仍要解决更老 Python 版本的向后兼容性问题）。这不适用于 Python 4 。我们仍在考虑对这两个构建的 ABI 兼容性和其他细节的要求，以及对向后兼容性的影响；
在我们承诺完全转向 no-GIL 之前，需要看到社区的支持。我们不能只是更改默认设置，更希望社区弄清自己需要做什么工作来给予支持。我们核心开发团队需要获得新构建模式及相关所有内容的经验。我们要整理现有代码中的线程安全性，因而需要弄明白新的 C API 和 Python API 。我们在获得这些洞见时还需要传达给 Python 社区的其他人，并确保自身想要做出的更改以及希望他们做出的更改是可取的；
在我们默认 no-GIL 设置之前的任何时候，如果事实证明了，它的破坏性太大导致收益太少，我们希望能够改变主意。这也就意味着我们会回滚所有工作，因此在我们确定要将 no-GIL 设为默认方式之前，特定于 no-GIL 的代码在某种程度上应是可识别的。

目前，我们认为未来的道路分为以下三个阶段：