Python 的 GIL 时代即将终结，迈向真正的多线程时代

Python 功能强大、灵活且对程序员友好，广泛应用于从 Web 开发到机器学习的各个领域。根据引用次数最多的两项指标，Python 甚至超越了 Java 和 C 等语言，成为最流行的编程语言。经过多年的流行，Python 似乎势不可挡。

但 Python 作为一种编程语言的未来发展至少面临一个重大障碍。它被称为 GIL，即全局解释器锁，几十年来，Python 开发人员一直试图将其从 Python 的默认实现中删除。

虽然 GIL 在确保线程安全方面发挥着至关重要的作用，但它同时也为多线程程序带来了严重的性能瓶颈。简单来说，GIL 阻碍了 Python 在多核处理器系统上发挥最大效能。很多人认为，如果 Python 想要成为并发编程的首选语言，那么 GIL 必须被废弃。

到目前为止，所有移除 GIL 的尝试都没有成功。但现在，新的一轮努力正在展开，目标是让 GIL 成为历史，让 Python 能够更好地满足未来编程的需求。

全局解释器锁（Global Interpreter Lock，简称 GIL）即将成为历史。这意味着 Python 将摆脱“伪多线程”的标签，迈向真正的并行处理。

“Python 的 GIL 时代即将终结，这对人工智能生态系统是一个巨大的胜利。” PyTorch 的核心维护者 Dmytro Dzhulgakov 激动地表示。

什么是 GIL

那么，GIL 究竟是什么呢？GIL，即全局解释器锁，虽然不是 Python 特有的，但它是在 CPython 解释器的开发过程中引入的一个概念。简单来说，GIL 就像是一个保护机制，确保在任何时刻只有一个线程能够执行 Python 代码，以维护代码的线程安全。

但 GIL 也有它的不足之处：它限制了 Python 在多核 CPU 上的并行处理能力，因为不论有多少个线程，一次只能在一个核心上运行，这大大降低了程序的运行效率。

为什么 Python 有 GIL

严格来说，全局解释器锁并非 Python 语言本身的一部分，而是最常用的 Python 实现版本 CPython 的一个组件，由 Python 软件基金会维护。

GIL 通过限制一次只能有一个线程执行 Python 代码，来确保 CPython 的线程安全。由于 CPython 的内存管理系统本身不支持多线程安全，GIL 便用来控制对对象和内存的访问，防止出现数据竞争。如果没有 GIL，CPython 就必须采用其他方式来处理并发和数据竞争问题。

GIL 为何会成为问题？首先，它阻止了 CPython 解释器实现真正的多线程。这使得 Python 难以实现其他编程语言中常见的代码加速优化。

大多数开发者以各种方式来规避 GIL 的限制。例如，多进程模块允许我们并行运行多个 Python 解释器实例（每个实例在各自的物理线程上），并在它们之间分配任务。但由于在不同 Python 实例间共享数据会产生较大的开销，多进程只适用于某些特定类型的问题。

另一种规避方法是使用 Python 的 C 语言扩展。这些扩展在 Python 解释器之外运行，因此它们处理的数据不受 GIL 的限制。但这种方法只有在处理纯 C 代码和数据结构时才有效，一旦涉及 Python 对象，问题依旧存在。所以，和多进程一样，C 扩展也只能解决一部分问题。

随着 Python 语言的日益流行，GIL 这一缺陷也越来越让人感到尴尬。因此，无论是过去还是现在，都有各种尝试和努力在进行，目的是摆脱 GIL 的束缚。

现在，Python 团队已经正式决定移除 GIL，并将其作为一个可选功能，这对开发者而言无疑是个好消息。

这一变革性的进展是由 Meta 的软件工程师 Sam Gross 在四年多的时间里努力完成的。

消息一出，业界纷纷叫好。深度学习领域的领军人物 Yann LeCun 也发来祝贺：没有了 GIL 的束缚，Python 代码现在可以自由地进行多线程操作了。

告别 GIL 的 Python。

随着 GIL 的退出，Python 的潜力将得到前所未有的释放，预示着一个性能大幅提升的未来。

让我们深入了解一下具体的细节。

CPython 的核心开发者 Thomas Wouters 详细阐述了无 GIL 版本的 Python，并对未来进行了展望。

对于大家就无 GIL 提议提出的宝贵反馈和普遍的积极支持，我们表示衷心的感谢。指导委员会计划采纳这一提议，并在下文中与大家分享更多细节。

我们的基本设想是：

• 长期来看（大约五年以上），无 GIL 版本的 Python 将成为唯一的选择；
• 我们非常重视向后兼容性。我们不希望重蹈 Python 3 升级时的覆辙，即所有第三方代码都需要修改以适应无 GIL 版本，而这些修改本应只针对有 GIL 版本（尽管与旧版 Python 的兼容性问题仍然需要解决）。Python 4 版本不会采用这种做法。我们还在考虑关于应用程序二进制接口（ABI）兼容性的要求，以及这两种版本在其他方面的细节，这些都会影响向后兼容性；
• 在我们决定全面转向无 GIL 之前，我们希望得到社区的支持。我们不能仅仅改变默认设置，我们需要社区的积极参与和支持。我们的核心开发团队需要时间来熟悉新的构建模式，包括 API 设计、打包和分发等方面。我们需要整理现有代码的线程安全问题，并开发新的 C 和 Python 接口。我们还需要将这些见解分享给 Python 社区的其他成员，并确保我们想要做出的改变，以及我们希望他人做出的改变，都是值得追求的；
• 在我们决定将无 GIL 作为默认设置之前，我们希望能够随时改变主意，如果事实证明这样的改变带来的破坏性太大而收益甚微。这也意味着，在我们将无 GIL 作为标准配置之前，所有与无 GIL 相关的代码都应该是可以识别的，以便回滚。

目前，我们将未来的路线图分为三个阶段：

• 短期内，我们将在 Python 3.13（可能还有 3.14）版本中，将无 GIL 版本作为一个实验性选项。之所以称之为实验性，是因为我们的核心开发团队虽然支持这一选项，但并不期望整个社区都会立即采用。我们需要时间来探索我们想要如何进行，至少在 API 设计、打包和分发方面，以便获得社区的支持。我们也不建议分销商将实验性的无 GIL 版本作为默认解释器发布。
• 中期，当我们确信社区的支持足够，使得无 GIL 版本的 Python 可以在生产环境中使用时，我们将支持这一版本，但不会立即作为默认选项。而是在某个特定的日期或 Python 版本中，将其设为默认。具体时间将取决于多种因素，比如 API 变更的兼容性如何，社区还需要完成多少工作等。我们预计这个阶段至少需要一到两年的时间。一旦我们宣布支持，一些分销商可能会开始默认提供无 GIL 版本的 Python。
• 长期来看，我们希望无 GIL 版本成为新标准，并彻底移除 GIL。我们不想拖延太久，毕竟，同时维护两种常用的构建模式会给社区带来沉重的负担，比如需要双倍的测试资源和调试场景。但我们也不能过于急功近利。我们预计这个过程大约需要五年的时间。

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

你对 GIL 将成为可选功能这一变化有何看法？

References

PEP 703 – Making the Global Interpreter Lock Optional in CPython：https://peps.python.org/pep-0703/

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