全局解释器锁 (GIL) 可以被移除。从此，Python 将不再是人们所说的伪多线程。
"Python 中的 GIL 将不复存在。人工智能生态系统的巨大胜利......"PyTorch 核心维护者 Dmytro Dzhulgakov 感慨地说。
什么是 GIL？GIL 的全称是全局解释器锁（Global Interpreter Lock），它不是 Python 独有的，而是在实现 CPython（Python 解释器）时引入的一个概念。我们可以把 GIL 理解为一种互斥，用来保护 Python 中的对象，防止多个线程同时执行 Python 字节码，从而确保线程安全。
但是，GIL 有一个缺点，即一个 CPU 一次只能执行一个线程，多个线程无法映射到多个 CPU，因此 Python 无法实现真正的多线程并发，从而降低了执行效率。
现在，Python 团队正式接受了移除 GIL 的提议，并将其作为一种可选模式，这对开发者来说是件好事。
这项贡献是由 Meta 公司一位名叫萨姆-格罗斯的软件工程师做出的，他花了四年多的时间才完成这个项目。
听到这个消息后，所有人都报以热烈的掌声。深度学习三巨头之一的 Yann LeCun 也发来了贺电：没有了 GIL，Python 代码现在可以自由执行多线程了。
Python 中不再有 GIL
详情
CPython 核心开发人员 Thomas Wouters 详细介绍了无 GIL Python 并展望了未来。
非常感谢大家对无 GIL 提议的反馈意见，以及总体上的积极支持。指导委员会打算接受无 GIL 提议，并在下文中与大家分享具体细节。
基本假设如下:
- 从长远来看（大约 5 年以上），无 GIL 版本应该是唯一的版本
- 我们希望非常小心地处理向后兼容性问题。我们不希望再出现 Python 3 的情况，即所有为适应无 GIL 版本而对第三方代码所做的修改都只适用于有 GIL 版本（尽管仍需解决与旧 Python 版本的向后兼容性问题）。这不适用于 Python 4。我们仍在考虑 ABI 兼容性的要求和这两种联编的其他细节，以及对向后兼容性的影响
- 在我们承诺完全转向无 GIL 之前，我们希望看到社区的支持。我们不能只是更改默认设置，我们希望社区能找出他们在做什么来支持我们。我们的核心开发团队需要在新的构建模式和所有相关方面积累经验。我们需要理清现有代码中的线程安全问题，还需要弄清楚新的 C API 和 Python API。我们还需要将这些见解传达给 Python 社区的其他人，并确保我们想做的改变和我们希望其他人做的改变都是可取的
- 在默认无 GIL 设置之前的任何时候，我们都希望能够改变主意，如果事实证明这样做破坏性太大而收益太少的话。这也意味着我们要回滚所有的工作，因此在我们决定将 no-GIL 设为默认设置之前，特定于 no-GIL 的代码在某种程度上应该是可识别的
目前，我们认为前进的道路分为三个阶段：
- 短期内，我们将把无 GIL 构建作为一种实验性的构建模式，可能会在 3.13（也可能在 3.14）中采用。说它是实验性的，是因为我们的核心开发团队虽然支持这种构建模式，但并不期望整个社区都支持它。我们需要时间来弄清楚我们要做什么，至少在 API 设计、打包和发布方面，这样我们才能获得社区的支持。我们也不鼓励发行商将实验性的无 GIL 版本作为默认解释器发布。
- 从中期来看，当我们确信社区的支持足以让 no-GIL 的生产使用变得可行之后，我们将支持 no-GIL 构建，但不是默认支持，而是在某个目标日期或某个 Python 版本中将其作为默认方式。具体时间将取决于很多因素，比如 API 变化最终的兼容性如何，社区认为他们还需要做多少工作，等等。我们预计这至少需要一到两年的时间。一旦我们宣布支持，预计一些发行商将开始默认提供无 GIL 版本
- 从长远来看，我们希望将无 GIL 设为默认模式，并删除 GIL 的所有痕迹（但不会不必要地破坏向后兼容性）。我们不想等太久，毕竟同时存在两种常用的构建模式会给社区带来很大负担（例如需要重复测试资源和调试场景）。但我们也不能操之过急。我们认为这个过程需要五年时间
当然，在整个过程中，我们的整个开发团队都需要实时评估进度，并对时间表进行调整。
评论区