Python 全局解释器锁 GIL 的重大新闻!-轻识

△点击上方“ Python猫 ”关注，回复“ 1 ”领取电子书

花下猫语：在最新一期 Python 周刊中（ 点击阅读 ），我分享了一则关于无 GIL 提案（PEP-703）的最新消息，这则消息已经引爆技术社区了！这里分享一篇文章，主要内容是对官方公告的翻译，可以一探后续的发展规划：

来源：机器之心

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 的代码在某种程度上应是可识别的。

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

短期内，我们会将 no-GIL 构建作为一种实验性构建模式，大概会在 3.13 版本（也有可能推迟到 3.14 版本）可用。之所以是实验性的，是因为我们核心开发团队虽然支持这一构建模式，但不期望整个社区都会支持它。我们需要时间理清自己要做什么，至少在 API 设计以及打包和分发方面，从而得到社区的支持。我们也不鼓励 distributor 将实验性 no-GIL 构建作为默认解释器发布。
中期来看，在我们确信得到足够的社区支持并使 no-GIL 的生产使用可行后，我们将支持 no-GIL 构建，但不是默认方式，而是在某个目标日期或某个 Python 版本中使它成为默认方式。具体的时间将取决于很多因素，比如 API 更改最终的兼容性如何、社区认为他们仍然需要做多少工作等。我们预计这至少需要一至两年的时间。一旦我们宣布支持，预计将有一些 distributor 会开始默认发布 no-GIL。
长期来看，我们希望 no-GIL 成为默认方式，并删除 GIL 的所有痕迹（但不会不必要地破坏向后兼容性）。我们不希望等太长时间，毕竟两种常用的构建模式同时存在会给社区造成很大的负担（比如需要双倍测试资源和 debug 场景）。但是我们也不能急于求成。我们认为这一过程将需要花费五年的时间。

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

参考链接：

https://discuss.python.org/t/a-steering-council-notice-about-pep-703-making-the-global-interpreter-lock-optional-in-cpython/30474

https://twitter.com/dzhulgakov/status/1685667015800066048

Python猫技术交流群开放啦！群里既有国内一二线大厂在职员工，也有国内外高校在读学生，既有十多年码龄的编程老鸟，也有中小学刚刚入门的新人，学习氛围良好！想入群的同学，请在公号内回复『交流群』，获取猫哥的微信（谢绝广告党，非诚勿扰！）~

还不过瘾？试试它们

▲Python 潮流周刊#13：Jupyter Notebook 7 发布了，无 GIL 提案传来大好消息！

▲Python潮流周刊#2：Rust让Python再次伟大

▲Python 项目工程化最佳实践指南

▲Python 程序调试分析大杀器合集

▲Python 优化提速的 8 个小技巧

▲Python潮流周刊#7：我讨厌用 asyncio

如果你觉得本文有帮助 请慷慨分享 和点赞 ，感谢啦 ！