Python 将移除 GIL！

经过反复讨论，Python/ target=_blank class=infotextkey>Python 指导委员会打算批准一项提案——PEP 703，这项提案具体是指："在 CPython 中使 GIL（全局解释器锁）成为可选项"。

该提案是多年来为移除 Python 的 GIL 而进行多次尝试的最终结果。移除 GIL 将解放多线程性能，使 Python 成为真正的多核语言，并显著提高其并行工作负载的性能。

有了这项提议，现实中 Python 中对多线程和并发性的支持更上一步。

为什么要移除 Python 的 GIL？

Python 的内存管理机制通过维护每个对象的引用计数来跟踪对象的使用情况。当某个对象的引用计数降为零时，该对象就会被移除。

由于 Python 诞生时，多处理器系统还很罕见，多核处理器也不存在，因此这种引用计数机制不能确保线程安全。

相反，Python 通过一次只允许一个线程访问一个对象来实现线程安全。这就是 GIL 的目的。

多年来，许多项目都试图移除 GIL。它们确实使多线程程序运行得更快，但代价是降低了单线程程序的性能。考虑到绝大多数 Python 应用程序都是单线程的，这种带来了弊大于利的局面。过去，虽然项目维护人员一直对 GIL 进行改进，但它仍然是一个严重的瓶颈。

Python 的核心开发人员最终决定从 CPython 中移除 GIL，但前提是不能降低单线程程序的运行速度。

无 GIL 的 Python 将如何运行

目前此提案对无 GIL 版本的 Python 的建议使用了多种技术，最终使引用计数线程安全，而对单线程程序的速度不产生影响或影响很小。

譬如：

• 有偏差的引用计数。对仅由单线程访问的对象进行计数的处理方式与对由多线程访问的对象进行计数的处理方式不同（处理速度更快）。
• 永生化。有些对象（如 None）永远不需要重新分配，因此不需要跟踪其引用计数。
• 线程安全的内存分配。CPython 对象的新内存分配系统将使垃圾回收器更容易跟踪对象，并以线程安全的方式分配内存。
• 延迟引用计数。某些对象（如模块中的顶层函数）的引用计数可以安全地延迟。这既节省了时间，也节省了资源。
• 改进的垃圾回收器。CPython 垃圾收集器会清理循环对象引用，即两个或多个对象之间的相互引用。无 GIL 版本对垃圾回收器进行了许多修改，例如删除了用于跟踪对象的 "生成 "系统。

如何逐步实现no-GIL Python

把 PEP 703 提案落实下来，其实需要一定的时间，甚至可能会在多年内分阶段进行。在此期间，CPython 解释器将过渡到使 no-GIL 版本首先成为可选版本，然后成为支持版本，最后成为 CPython 的标准版本。

为了实现这一目标，CPython 的开发人员将在 CPython 中添加具有实验性的 "no-GIL "编译模式，这样人们就可以编译带有或不带 GIL 的 CPython 版本。最终，无 GIL 编译模式将成为默认模式。

以下是从 CPython 中移除 GIL 的计划的展开过程。

第一步：让无 GIL CPython 成为可选项

对于 CPython 开发者和更大的 Python 社区来说，无 GIL CPython 的第一个版本是实验性版本。这一实验阶段有几个目标：

• 让 Python 社区的其他成员参与进来。Python 的任何重大改变都需要更广泛的 Python 社区的支持。实验性构建为 Python 用户提供了一种安全测试其代码的方法，并让他们了解非线程代码和线程代码将如何运行。
• 为 Python 发行版提供发布 no-GIL 的选项，而不是直接要求。像 Conda 或 WinPython 这样的 Python 发行版需要保证与现有 CPython 的兼容性。在过渡阶段，它们可以提供安装常规或无 GIL 版本 CPython 的选项。这将允许 Conda 或 WinPython 用户选择最符合其需求的版本。
• 确定 no-GIL 项目是否值得。如果社区大规模试用 no-GIL 构建，并对结果不满意，CPython 核心开发人员保留退出的权利。双重构建意味着在短期内会增加维护负担，但如果 no-GIL 项目证明不值得，他们也有退路。

第二步：让 No-GIL CPython 成为支持版本

下一阶段将提供 no-GIL 构建，作为 CPython 受支持的替代构建。用户可以选择安装 no-GIL 或 GIL 版本，其中任何一个版本都是 CPython 的正式支持版本，会收到错误修复、安全补丁和更新。

本阶段的一个重要目标是设定一个目标日期，将 no-GIL 变为默认版本。这可能会与其他 Python 功能的废弃和移除发生在同一时间段上——至少需要经历两三个版本的迭代，也就是至少两三年的时间。

第三步：让 no-GIL CPython 成为默认版本

最后一个阶段是将 no-GIL 版本的 CPython 作为默认值，并从 CPython 中移除所有与 GIL 相关的代码。

CPython 核心开发人员 Thomas Wouters 写道："我们不想在这个问题上等待太久，因为拥有两种通用构建模式可能会给社区带来沉重负担（例如，这会使测试资源和调试场景增加一倍），但我们也不能操之过急。我们认为要达到这一阶段可能需要长达五年的时间"。

取消 GIL 面临的最大挑战

尽管技术上的挑战令人生畏，但这一计划所面临的最大挑战并不仅仅是技术上的。更大的挑战在于如何让 Python 生态系统的其他部分与这些变化保持一致，并确保无 GIL 的 Python 不会带来比解决更多的问题。

根据 Wouters 的说法，"......为适应 no-GIL 版本而需要对第三方代码进行的任何修改，都应该能在有 GIL 版本中正常运行（尽管仍需要解决与旧 Python 版本的向后兼容性问题）"。

如上所述，另一个巨大的挑战是“让 Python 社区的其他成员也参与进来.....并确保我们希望做出的改变和我们希望他们做出的改变都能被接受”，Wouters 说道。

Wouters 表示：“在我们承诺完全转向 no-GIL 构建之前，我们需要看到社区对它的支持。我们不能只是将其设置为默认值，然后期待社区找出他们需要做哪些工作来支持它”。

Python 社区在从 Python 2 过渡到 Python 3 的过程中经历了巨大的成长之痛，因此任何像移除 GIL 这样的重大改变都必须彻底向后兼容。正如 Wouters 所说，"我们不希望再出现 Python 3 的情况"。

除了危险和挑战之外，还有一个巨大的回报：Python 最终支持了程序员在 21 世纪所期待的并行性。