Python社区变天：可去除全局解释器锁GIL，真正多线程要来了
机器之心报道， 编辑：杜伟、陈萍。
「Python 中的 GIL 将不复存在，这是人工智能生态系统领域中的巨大胜利。」PyTorch 核心维护者 Dmytro Dzhulgakov 感慨道。
GIL 是什么？GIL 的全称是 Global Interpreter Lock（全局解释器锁），它不是 Python 独有的，而是在实现 CPython（Python 解释器）时引入的一个概念。我们可以将 GIL 理解为一个互斥锁，用来保护 Python 里的对象，防止同一时刻多个线程执行 Python 的字节码，从而确保线程安全。
图源： https:// realpython.com/python-g il/
然而，GIL 存在一个弊端，即在同一时刻只能有一个线程在一个 CPU 上执行，无法将多个线程映射到多个 CPU 上，使得 Python 并不能实现真正的多线程并发，从而降低了执行效率。
现在， Python 团队已经正式接受了删除 GIL 的这个提议，并将其设置为可选模式 ，可谓是利好广大开发者。
做出这一贡献的是一位来自 Meta 的名叫 Sam Gross 的软件工程师，他花费了四年多的时间才完成这一工程。
在得知这一消息后，大家纷纷叫好，深度学习三巨头之一的 Yann LeCun 发文祝贺：没有了 GIL，现在，Python 代码可以自由的执行多线程了。
「Python 中终于没有 GIL 了！」
「这是一个里程碑式的决定，是编码社区所热切期待的。」
具体细节如何，我们接着看下文。
CPython 核心开发者 Thomas Wouters 撰文描述了 Python 中的无 GIL 细节，并对未来发展做了展望。
非常感谢所有人对无 GIL 提议的反馈，整体上都持积极的支持态度。指导委员会打算接受无 GIL 提议，并就以下具体细节与大家分享。
目前，我们认为未来的道路分为以下三个阶段：
- 短期内，我们会将 no-GIL 构建作为一种实验性构建模式，大概会在 3.13 版本（也有可能推迟到 3.14 版本）支持。之所以是实验性的，是因为即使我们核心开发团队支持这一构建模式，但不期望整个社区都会支持它。我们需要时间理清自己要做什么，至少在 API 设计以及打包和分发方面，并得到社区的支持。在此，我们也不鼓励 distributor 将实验性 no-GIL 构建作为默认解释器发布。
- 中期来看，在我们确信得到足够的社区支持并使 no-GIL 的生产使用可行后，我们将支持 no-GIL 构建，但不是以默认方式，而是在某个目标日期或某个 Python 版本中成为默认方式。具体时间取决于很多因素，比如 API 更改最终的兼容性如何、社区能为我们做多少工作等。我们预计这至少需要一至两年的时间。
- 长期来看，我们希望 no-GIL 成为默认方式，并删除 GIL 的所有痕迹（但不会不必要地破坏向后兼容性）。我们不希望等太长时间，毕竟两种常用的构建模式同时存在会给社区造成很大的负担（比如需要双倍测试资源和 debug 场景）。但我们也不能急于求成。我们认为这一过程将花费五年的时间。
当然在整个过程中，我们整个开发团队将需要实时评估进程并对时间线进行调整。
评论区的小伙伴们，你们对 GIL 成为可选是什么看法呢？
