GIL 使许多类型的并行性难以表达

基于神经网络的 AI 模型展现出多种并行机会。例如，单个操作可以在内部并行化 (“操作内”)，多个操作可以同时执行 (“操作间”)，请求（跨越多个操作）也可以并行化。有效执行需要利用多种类型的并行性 [1]。

GIL 使得在 Python 中难以有效地表达操作间并行性以及某些形式的请求并行性。在其他编程语言中，系统可能会使用线程在不同的 CPU 内核上运行神经网络的不同部分，但在 Python 中，由于 GIL，这效率低下。类似地，延迟敏感的推理工作负载经常使用线程跨请求进行并行化，但在 Python 中面临着相同的扩展瓶颈。

GIL 对在 Python 中利用并行性提出的挑战经常出现在强化学习中。Heinrich Kuttler 是 NetHack 学习环境的作者，也是 Inflection AI 的技术人员，他写道

强化学习的最新突破，例如在 Dota 2、星际争霸 和 NetHack 上取得的突破，依赖于使用异步演员-评论家方法并行运行多个环境（模拟游戏）。Python 中直接的多线程实现由于 GIL 争用，无法扩展到超过几个并行环境。多处理（通过共享内存或 UNIX 套接字进行通信）增加了很大的复杂性，实际上排除了从不同工作进程与 CUDA 的交互，严重限制了设计空间。

Manuel Kroiss 是 DeepMind 强化学习团队的软件工程师，他描述了 GIL 带来的瓶颈如何导致 Python 代码库的重写，使用 C++，从而降低代码的可访问性

我们在 DeepMind 经常与 Python GIL 作斗争。在我们的许多应用程序中，我们希望在每个进程中运行大约 50-100 个线程。然而，我们经常发现，即使少于 10 个线程，GIL 也成为了瓶颈。为了解决这个问题，我们有时会使用子进程，但在许多情况下，进程间通信的开销过大。为了处理 GIL，我们通常最终将 Python 代码库的大部分内容转换为 C++。这是不希望的，因为它降低了研究人员对代码的访问性。

涉及与多个硬件设备交互的项目面临着类似的挑战：高效通信需要使用多个 CPU 内核。Dose-3D 项目旨在通过精确的剂量规划来改善癌症放射治疗。它使用医疗模型（人体组织的替代品）以及自定义硬件和用 Python 编写的服务器应用程序。Dose-3D 项目数据采集系统首席软件架构师 Paweł Jurgielewicz 描述了 GIL 带来的扩展挑战，以及如何使用没有 GIL 的 Python 分支简化了项目

在 Dose-3D 项目中，关键挑战是保持与硬件单元的稳定、非平凡的并发通信链路，同时将 1 Gbit/s UDP/IP 连接利用到最大限度。当然，我们首先尝试使用 multiprocessing 包，但后来发现，大多数 CPU 时间都花在了数据处理阶段之间的传输上，而不是数据处理本身。基于 GIL 的 CPython 多线程实现也是一个死胡同。当我们发现“nogil”分支的 Python 时，一个人不到半天的时间就调整了代码库以使用这个分支，结果令人震惊。现在，我们可以专注于数据采集系统开发，而不是微调数据交换算法。

Allen Goodman 是 CellProfiler 的作者，也是 Prescient Design 和 Genentech 的高级工程师，他描述了 GIL 如何在 Python 中使生物方法研究变得更加困难

Python 全局解释器锁的问题是整个生物方法研究中经常遇到的挫折来源。

我想要更好地了解当前的多线程情况，所以我重新实现了 HMMER 的部分内容，这是一种用于多序列比对的标准方法。我选择这种方法是因为它既强调单线程性能（评分），也强调多线程性能（搜索序列数据库）。当仅使用 8 个线程时，GIL 成为瓶颈。这是一种方法，其中当前流行的实现依赖于每个进程 64 个甚至 128 个线程。我尝试使用子进程，但被高昂的 IPC 成本所阻止。HMMER 是一种相对基本的生物信息学方法，而更新的方法对多线程的需求更大。

方法研究人员恳求使用 Python（包括我自己），因为它易于使用，Python 生态系统，以及“这是人们所知的东西”。许多生物学家只懂一点编程（而且几乎总是 Python）。在 Python 的多线程问题得到解决之前，C 和 C++ 将仍然是生物方法研究界的通用语言。

GIL 影响 Python 库的可用性

GIL 是 CPython 实现细节，它限制了多线程并行性，因此将其视为可用性问题似乎不直观。但是，库作者经常非常关心性能，并将设计支持绕过 GIL 的 API。这些解决方法通常会导致更难使用的 API。因此，使用这些 API 的用户可能会将 GIL 视为可用性问题，而不仅仅是性能问题。

例如，PyTorch 公开了一个基于多处理的 API，称为 DataLoader，用于构建数据输入管道。它在 Linux 上使用 fork()，因为它通常更快，并且比 spawn() 使用更少的内存，但这会导致用户面临更多挑战：在访问 GPU 后创建 DataLoader 会导致令人困惑的 CUDA 错误。在 DataLoader 工作进程中访问 GPU 很快会导致内存不足错误，因为进程不共享 CUDA 上下文（与进程内的线程不同）。

Olivier Grisel 是 scikit-learn 的开发者，也是 Inria 的软件工程师，他描述了如何必须在 scikit-learn 相关库中绕过 GIL，从而导致用户体验更加复杂和令人困惑

多年来，scikit-learn 开发人员一直维护着一些辅助库，例如 joblib 和 loky，以尝试解决多处理的一些局限性：通过对大型数据缓冲区的半自动化内存映射来部分缓解额外的内存使用，通过透明地重用一个长期运行的 worker 池来加快 worker 启动速度，通过永远不使用 fork-only 启动方法来解决诸如 GNU OpenMP 之类的第三方原生运行时库的 fork 安全性问题，通过 cloudpickle 以跨平台的方式在笔记本和 REPL 中执行交互式定义的函数的并行调用。尽管我们付出了努力，但这种基于多处理的解决方案仍然很脆弱，维护起来很复杂，而且对于对系统级约束了解有限的数据科学家来说也很令人困惑。此外，仍然存在不可消除的局限性，例如进程间通信所需的基于 pickle 的序列化/反序列化步骤造成的开销。如果我们能够在多核主机（有时具有 64 个或更多物理核心）上使用线程来运行数据科学管道，而这些管道在 Python 级操作和对原生库的调用之间交替进行，那么这些额外的工作和复杂性将不再需要了。

Quansight Labs 联合主管、NumPy 和 SciPy 维护者 Ralf Gommers 描述了 GIL 如何影响 NumPy 和数值 Python 库的用户体验

NumPy 及其周围的软件包栈中的一个关键问题是，NumPy 仍然（大部分）是单线程的——这影响了用户体验和围绕它构建的项目的重要部分。NumPy 在其内部循环（执行繁重工作）中确实会释放 GIL，但这还不够。NumPy 没有提供解决方案来充分利用单台机器的所有 CPU 内核，而是将此留给了 Dask 和其他多处理解决方案。这些解决方案效率不高，使用起来也更笨拙。这种笨拙主要体现在用户在使用（例如）dask.array（它包装了 numpy.ndarray）时需要关注的额外抽象和层。它还出现在用户必须显式地了解和管理的过度订阅问题中，可以通过环境变量或第三方包 threadpoolctl 来管理。主要原因是 NumPy 调用 BLAS 进行线性代数——它无法控制这些调用，它们默认情况下会通过 pthreads 或 OpenMP 使用所有内核。

协调 API 和设计决策以控制并行性仍然是一项大量工作，也是 PyData 生态系统中更难的挑战之一。如果没有 GIL，情况会大不相同（更好，更简单）。

GPU 密集型工作负载需要多核处理

许多高性能计算 (HPC) 和 AI 工作负载大量使用 GPU。这些应用程序通常需要高效的多核 CPU 执行，即使大部分计算在 GPU 上运行。

PyTorch 核心开发者、FAIR（Meta AI）研究员 Zachary DeVito 描述了 GIL 如何使多线程扩展效率低下，即使大部分计算是在 Python 之外执行的

在 PyTorch 中，Python 通常用于协调约 8 个 GPU 和约 64 个 CPU 线程，对于大型模型，扩展到 4k 个 GPU 和 32k 个 CPU 线程。虽然繁重的工作是在 Python 之外完成的，但 GPU 的速度使得即使是 Python 中的协调也无法扩展。由于 GIL 的存在，我们经常使用 72 个进程来代替一个进程。在这种情况下，日志记录、调试和性能调优的难度要大几个数量级，导致开发者效率持续下降。

使用多个进程（而不是线程）使常见任务变得更加困难。Zachary DeVito 继续说道

在过去的几个月里，我有三次（减少数据加载器中的冗余计算、异步写入模型检查点和并行化编译器优化），我在解决 GIL 限制方面花费的时间比实际解决特定问题的时间多了一个数量级。

即使是 GPU 密集型工作负载也经常有 CPU 密集型组件。例如，计算机视觉任务通常需要在数据输入管道中执行多个“预处理”步骤，例如图像解码、裁剪和调整大小。这些任务通常在 CPU 上执行，并可能使用 Python 库（如 Pillow 或 Pillow-SIMD）。为了让 GPU 不断“获得”数据，必须在多个 CPU 内核上运行数据输入管道。

与单个 CPU 内核相比，GPU 性能的提升使多核性能更加重要。让 GPU 保持完全占用变得越来越困难。这样做需要高效地使用多个 CPU 内核，尤其是在多 GPU 系统上。例如，NVIDIA 的 DGX-A100 拥有 8 个 GPU 和两个 64 核 CPU，以确保 GPU 不断“获得”数据。

GIL 使部署 Python AI 模型变得困难

Python 广泛用于开发基于神经网络的 AI 模型。在 PyTorch 中，模型通常作为多线程（主要是 C++）环境的一部分进行部署。Python 经常受到怀疑，因为 GIL 可能成为全局瓶颈，即使大多数计算发生在 Python 之外，GIL 被释放，也无法有效扩展。torchdeploy 论文 [2] 展示了这些扩展瓶颈在多个模型架构中的实验性证据。

PyTorch 提供了一些机制来部署 Python AI 模型，这些机制可以避免或绕过 GIL，但它们都存在很大的局限性。例如，TorchScript 捕获了模型的表示形式，可以从 C++ 中执行，没有任何 Python 依赖关系，但它只支持 Python 的有限子集，通常需要重写模型的一些代码。该 torch::deploy API 允许在同一个进程中使用多个 Python 解释器，每个解释器都有自己的 GIL（类似于 PEP 684）。但是，torch::deploy 对使用 C-API 扩展的 Python 模块的支持有限。

动机总结

Python 的全局解释器锁使得难以在许多科学和数值计算应用中有效地使用现代多核 CPU。Heinrich Kuttler、Manuel Kroiss 和 Paweł Jurgielewicz 发现，Python 中的多线程实现无法很好地扩展，而使用多个进程也不是一个合适的替代方案。

扩展瓶颈并不仅仅存在于核心数值任务中。Zachary DeVito 和 Paweł Jurgielewicz 都描述了 Python 中协调和通信的挑战。

Olivier Grisel、Ralf Gommers 和 Zachary DeVito 描述了当前解决 GIL 的方法是如何“维护起来很复杂”以及如何导致“开发者效率下降”。GIL 使开发和维护科学和数值计算库变得更加困难，也导致库设计更难使用。

构建配置更改

全局解释器锁将仍然是 CPython 构建和 python.org 下载的默认值。一个新的构建配置标志 --disable-gil 将被添加到配置脚本中，该脚本将构建支持在没有全局解释器锁的情况下运行的 CPython。

当使用 --disable-gil 构建时，CPython 将在 Python/patchlevel.h 中定义 Py_GIL_DISABLED 宏。ABI 标签将包含字母“t”（表示“线程”）。

使用 --disable-gil 构建的 CPython 仍然支持在运行时选择性地启用 GIL（参见 PYTHONGIL 环境变量 和 Py_mod_gil 槽）。

CPython 更改概述

删除全局解释器锁需要对 CPython 内部进行大量更改，但对公共 Python 和 C API 的更改相对较少。本节介绍对 CPython 实现的必要更改，然后介绍提议的 API 更改。

实现更改可以分为以下四类

• 引用计数
• 内存管理
• 容器线程安全性
• 锁定和原子 API

引用计数

删除 GIL 需要对 CPython 的引用计数实现进行更改，以使其线程安全。此外，它需要具有较低的执行开销，并允许与多个线程一起有效扩展。本 PEP 提出结合三种技术来解决这些限制。首先是从简单的非原子引用计数切换到有偏引用计数，这是一种线程安全的引用计数技术，其执行开销低于简单的原子引用计数。另外两种技术是永生化和有限形式的延迟引用计数；它们通过避免一些引用计数修改来解决引用计数的一些多线程可扩展性问题。

有偏引用计数 (BRC) 是一种技术，最早由 Jiho Choi、Thomas Shull 和 Josep Torrellas 于 2018 年提出 [3]。它基于这样的观察：即使在多线程程序中，大多数对象也只被单个线程访问。每个对象都与一个拥有线程（创建它的线程）相关联。来自拥有线程的引用计数操作使用非原子指令来修改“本地”引用计数。其他线程使用原子指令来修改“共享”引用计数。这种设计避免了许多原子读-修改-写操作，这些操作在当代处理器上很昂贵。

本 PEP 中提出的 BRC 实现大体上与有偏引用计数的原始描述相符，但在细节方面有所不同，例如引用计数字段的大小以及这些字段中的特殊位。BRC 需要在每个对象的标头中存储三条信息：“本地”引用计数、“共享”引用计数和拥有线程的标识符。BRC 论文将这三件事打包到一个 64 位字段中。本 PEP 提出在每个对象的标头中使用三个独立的字段，以避免由于引用计数溢出而可能出现的问题。此外，PEP 支持更快的释放路径，在常见情况下可以避免原子操作。

提议的 PyObject 结构（也称为 struct _object）如下所示

struct _object {
  _PyObject_HEAD_EXTRA
  uintptr_t ob_tid;         // owning thread id (4-8 bytes)
  uint16_t __padding;       // reserved for future use (2 bytes)
  PyMutex ob_mutex;         // per-object mutex (1 byte)
  uint8_t ob_gc_bits;       // GC fields (1 byte)
  uint32_t ob_ref_local;    // local reference count (4 bytes)
  Py_ssize_t ob_ref_shared; // shared reference count and state bits (4-8 bytes)
  PyTypeObject *ob_type;
};

该 ob_tid、ob_ref_local 和 ob_ref_shared 用于有偏引用计数实现。该 ob_gc_bits 字段用于存储之前存储在 PyGC_Head 中的垃圾回收标志（参见 垃圾回收（循环回收））。该 ob_mutex 字段在一个字节中提供每个对象的锁。

// low two bits of "ob_ref_shared" are used for flags
#define _Py_SHARED_SHIFT 2

void Py_INCREF(PyObject *op)
{
  uint32_t new_local = op->ob_ref_local + 1;
  if (new_local == 0)
    return;  // object is immortal
  if (op->ob_tid == _Py_ThreadId())
    op->ob_ref_local = new_local;
  else
    atomic_add(&op->ob_ref_shared, 1 << _Py_SHARED_SHIFT);
}

void Py_DECREF(PyObject *op)
{
  if (op->ob_ref_local == _Py_IMMORTAL_REFCNT) {
    return;  // object is immortal
  }
  if (op->ob_tid == _Py_ThreadId()) {
    op->ob_ref_local -= 1;
    if (op->ob_ref_local == 0) {
      _Py_MergeZeroRefcount(); // merge refcount
    }
  }
  else {
    _Py_DecRefShared(); // slow path
  }
}

void _Py_MergeZeroRefcount(PyObject *op)
{
  if (op->ob_ref_shared == 0) {
    // quick deallocation code path (common case)
    op->ob_tid = 0;
    _Py_Dealloc(op);
  }
  else {
    // slower merging path not shown
  }
}

内存管理

CPython 目前使用一个内部分配器 pymalloc，它针对小型对象分配进行了优化。pymalloc 实现如果没有 GIL 则不是线程安全的。这个 PEP 提出用 mimalloc 替换 pymalloc，mimalloc 是一个通用线程安全分配器，具有良好的性能，包括针对小型分配。

使用 mimalloc，并进行一些修改，还可以解决与移除 GIL 相关的另外两个问题。首先，遍历 mimalloc 内部结构允许垃圾回收器找到所有 Python 对象，而无需维护一个链表。这在垃圾回收部分有更详细的描述。其次，基于大小类的 mimalloc 堆和分配使像 dict 这样的集合通常可以在只读操作期间避免获取锁。这在集合线程安全性部分有更详细的描述。

CPython 已经要求支持垃圾回收的对象使用 GC 分配器 API（通常通过调用 PyType_GenericAlloc 间接调用）。这个 PEP 将对 Python 分配器 API 的使用添加额外的要求。首先，Python 对象必须通过对象分配 API 分配，例如 PyType_GenericAlloc、 PyObject_Malloc 或其他包装这些调用的 Python API。Python 对象不应该通过其他 API 分配，例如对 C 的 malloc 的原始调用或 C++ 的 new 运算符。此外， PyObject_Malloc 应该只用于分配 Python 对象；它不应该用于分配缓冲区、存储区或其他不是 PyObjects 的数据结构。

这个 PEP 还对可插拔分配器 API (PyMem_SetAllocator) 施加了限制。在不使用 GIL 的情况下编译时，使用此 API 设置的分配器最终必须将分配委托给相应的底层分配器，例如 PyObject_Malloc，用于 Python 对象分配。这允许“包装”底层分配器的分配器，例如 Python 的 tracemalloc 和调试分配器，但不允许完全替换分配器。

垃圾收集（循环收集）

CPython 垃圾回收器需要以下更改才能与这个提案一起工作

• 使用“停止世界”来提供以前由 GIL 提供的线程安全保证。
• 取消分代垃圾回收，转而使用非分代垃圾回收器。
• 与延迟引用计数和带偏置的引用计数集成。

此外，上述更改允许从 GC 对象中删除 _gc_prev 和 _gc_next 字段。存储跟踪、已完成和不可达状态的 GC 位已移至 PyObject 标头中的 ob_gc_bits 字段。

容器线程安全

在 CPython 中，全局解释器锁可防止在多个线程同时访问或修改 Python 对象时发生内部解释器状态损坏。例如，如果多个线程同时修改同一个列表，GIL 会确保列表的长度 (ob_size) 准确地匹配元素数量，并且每个元素的引用计数准确地反映对这些元素的引用数量。没有 GIL——如果没有其他更改——并发修改会损坏这些字段，并可能导致程序崩溃。

GIL 不一定保证操作是原子的或在多个操作同时发生时保持正确。例如，如果迭代器在 Python 中实现（或在内部释放 GIL），则 list.extend(iterable) 可能不会显得原子。类似地，如果 list.remove(x) 与另一个修改列表的操作重叠，则它可能会删除错误的对象，具体取决于相等运算符的实现。尽管如此，GIL 仍确保某些操作实际上是原子的。例如，构造函数 list(set) 将集合的项目原子地复制到一个新列表中，并且一些代码依赖于该复制是原子的（即对集合中项目的快照）。此 PEP 保留了该属性。

此 PEP 建议使用每个对象锁来提供与 GIL 提供的许多相同的保护。例如，每个列表、字典和集合都将有一个关联的轻量级锁。所有修改对象的运算都必须持有该对象的锁。大多数从对象读取的运算也应该获取该对象的锁；可以不持有锁进行的少数读取操作将在下面描述。

具有临界区的每个对象锁提供的保护比 GIL 弱。由于 GIL 不一定保证并发操作是原子的或正确的，因此每个对象锁定方案也不能保证并发操作是原子的或正确的。相反，每个对象锁定旨在提供与 GIL 相似的保护，但互斥限制在单个对象。

对容器类型实例的大多数操作都需要锁定该对象。例如

• list.append、list.insert、list.repeat、PyList_SetItem
• dict.__setitem__、PyDict_SetItem
• list.clear、dict.clear
• list.__repr__、dict.__repr__ 等。
• list.extend(iterable)
• setiter_iternext

某些操作直接对两个容器对象进行操作，并了解这两个容器的内部结构。例如，list.extend(iterable) 针对特定可迭代类型（如 set）的内部专业化。这些操作需要锁定两个容器对象，因为它们同时访问两个对象的内部。请注意，list.extend 的通用实现只需要锁定一个对象（列表），因为另一个对象是通过线程安全的迭代器 API 间接访问的。锁定两个容器的操作是

• list.extend(list)、list.extend(set)、list.extend (dictitems)，以及其他实现针对参数类型进行专门化的专业化。
• list.concat(list)
• list.__eq__(list)、dict.__eq__(dict)

一些简单的操作可以使用原子访问直接实现，并且不需要锁，因为它们只访问单个字段。这些操作包括

• len(list) 即，list_length(PyListObject *a)
• len(dict)
• len(set)

选择的操作会乐观地避免锁定以提高性能。这些操作需要特殊的实现和内存分配器的配合

• list[idx] (list_subscript)
• dict[key] (dict_subscript)
• listiter_next、dictiter_iternextkey/value/item
• list.contains

PyObject *item = PyList_GetItem(list, idx);
Py_INCREF(item);

Py_INCREF(a->ob_item[i]);
return a->ob_item[i];

 PyObject **ob_item = atomic_load(&a->ob_item);
 PyObject *item = atomic_load(&ob_item[i]);
 if (!item || !_Py_TRY_INCREF(item)) goto retry;
 if (item != atomic_load(&ob_item[i])) {
   Py_DECREF(item);
   goto retry;
 }
 if (ob_item != atomic_load(&a->ob_item)) {
   Py_DECREF(item);
   goto retry;
}
return item;

retry:
  PyObject *item;
  Py_BEGIN_CRITICAL_SECTION(a->ob_mutex);
  item = a->ob_item[i];
  Py_INCREF(item);
  Py_END_CRITICAL_SECTION(a->ob_mutex);
  return item;

专业化解释器

当在没有 GIL 的情况下运行时，专门的解释器需要一些更改才能使它线程安全。

• 通过使用互斥锁来防止并发专门化。这防止了多个线程写入同一个内联缓存。
• 在没有 GIL 的情况下运行的多线程程序中，每个字节码只专门化一次。这防止了一个线程读取部分写入的内联缓存。
• 锁定还确保 tp_version_tag 和 keys_version 的缓存值与缓存的描述符和其他值一致。
• 对内联计数器的修改使用“松弛原子”。换句话说，一些计数器递减可能会被遗漏或覆盖，但这不会影响正确性。

Py_mod_gil 槽

在 --disable-gil 构建中，当加载扩展时，CPython 会检查新的 PEP 489 风格的 Py_mod_gil 插槽。如果该插槽被设置为 Py_mod_gil_not_used，则扩展加载会像往常一样进行。如果该插槽未设置，解释器将暂停所有线程并在继续之前启用 GIL。此外，解释器会发出一个可见的警告，其中命名了扩展，说明 GIL 已启用（以及原因）以及用户可以采取的步骤来覆盖它。

PYTHONGIL 环境变量

在 --disable-gil 构建中，用户还可以通过设置 PYTHONGIL 环境变量来在运行时覆盖行为。设置 PYTHONGIL=0 强制禁用 GIL，覆盖模块插槽逻辑。设置 PYTHONGIL=1 强制启用 GIL。

PYTHONGIL=0 覆盖很重要，因为即使在多线程应用程序中，不安全的扩展仍然有用。例如，可能希望仅从单个线程使用扩展或通过锁保护访问。作为背景，即使使用 GIL，也有一些扩展是不安全的，用户已经不得不采取这些步骤。

PYTHONGIL=1 覆盖有时对调试很有用。

非分代垃圾收集

此 PEP 提议从分代循环垃圾收集器切换到非分代收集器（当 CPython 在没有 GIL 的情况下构建时）。这等同于只有一个代（“旧”代）。此提议更改有两个原因。

循环垃圾收集，即使只是针对年轻代，也需要暂停程序中的其他线程。作者担心频繁收集年轻代会抑制多线程程序的有效扩展。这是对年轻代（但不是老一代）的一个担忧，因为年轻代在固定数量的分配后被收集，而老一代的收集是根据堆中活动对象的数目按比例安排的。此外，在没有 GIL 的情况下，难以有效地跟踪每个代中的对象。例如，CPython 目前在每个代中使用一个对象的链接列表。如果 CPython 要保留该设计，则这些列表需要变得线程安全，而且目前尚不清楚如何高效地做到这一点。

分代垃圾收集在许多其他语言运行时中得到了很好的应用。例如，许多 Java HotSpot 垃圾收集器实现使用多个代 [11]。在这些运行时中，年轻代通常是一个吞吐量优势：由于大部分年轻代对象通常是“死亡”的，因此 GC 能够回收与执行工作量相比更多的内存。例如，一些 Java 基准测试表明，通常超过 90% 的“年轻”对象被收集 [12] [13]。这通常被称为“弱分代假设”；观察结果是大多数对象在年轻时就死亡。由于使用了引用计数，这种模式在 CPython 中被反转。虽然大多数对象仍然在年轻时就死亡，但它们在引用计数达到零时会被收集。在垃圾收集周期中幸存下来的对象很可能仍然存活 [14]。这种差异意味着，分代收集在 CPython 中比在许多其他语言运行时中的效果要差得多 [15]。

在 dict 和 list 访问中乐观地避免锁定

本提案依赖于一种方案，该方案在访问列表和字典中的单个元素时，大部分情况下会避免获取锁。请注意，这在“无锁”和“无等待”算法保证向前进度的意义上并不是“无锁”。它只是在常见情况下避免获取锁（互斥锁），以提高并行性和降低开销。

一个更简单的替代方法是使用读写锁来保护字典和列表访问。读写锁允许并发读取，但不允许更新，这似乎非常适合列表和字典。问题是读写锁有很大的开销，可扩展性很差，尤其是在关键部分很小时，比如对单个元素字典和列表的访问时 [9]。读者的可扩展性差源于这样一个事实，即所有读者都必须更新相同的数据结构，例如 pthread_rwlocks 中的读者数量。

本 PEP 中描述的技术与 RCU（“读-复制-更新”） [6] 以及在一定程度上与危险指针相关，危险指针是用于优化并发、以读取为主的数据结构的两种知名方案。RCU 被广泛用于 Linux 内核，以可扩展的方式保护共享数据结构。本 PEP 中的技术和 RCU 都通过在读者可能正在访问并发数据结构时延迟回收来工作。RCU 最常用于保护单个对象（如哈希表或链接列表），而本 PEP 提议了一种保护更大内存块（mimalloc “页面”）的方案 [10]。

对这种方案的需求很大程度上是由于 CPython 中使用了引用计数。如果 CPython 只依赖于追踪垃圾收集器，那么这种方案可能就不需要了，因为追踪垃圾收集器已经以所需的方式延迟了回收。这不会“解决”扩展性问题，但会将许多挑战转移到垃圾收集器实现上。

多处理

multiprocessing 库允许 Python 程序启动和与 Python 子进程通信。这允许并行处理，因为每个子进程都有自己的 Python 解释器（即，每个进程有一个 GIL）。多处理有一些实质性的限制。进程之间的通信受到限制：对象通常需要被序列化或复制到共享内存。这会引入开销（由于序列化）并使在多处理之上构建 API 变得复杂。启动子进程也比启动线程更昂贵，尤其是在“生成”实现中。启动线程需要约 100 µs，而生成子进程需要约 50 毫秒（50,000 µs），因为 Python 重新初始化。

最后，许多 C 和 C++ 库支持从多个线程访问，但不支持跨多个进程访问或使用。

在 C-API 扩展中释放 GIL

C-API 扩展可以在长时间运行的函数周围释放 GIL。这允许一定程度的并行处理，因为多个线程可以在 GIL 被释放时并发运行，但获取和释放 GIL 的开销通常会阻止此方法在超过几个线程的情况下有效扩展。许多科学计算库在计算密集型函数中释放 GIL，而 CPython 标准库在阻塞 I/O 周围释放 GIL。

内部并行化

在 C 中实现的函数可能在内部使用多个线程。例如，英特尔的 NumPy 分发、PyTorch 和 TensorFlow 都使用这种技术来内部并行化各个操作。当基本操作足够大以有效地并行化时，这很有效，但当有许多小的操作或操作依赖于一些 Python 代码时，则不然。从 C 调用 Python 需要获取 GIL - 即使是简短的 Python 代码片段也会抑制扩展。

每个解释器 GIL

最近接受的 PEP 684 提出了一个每解释器 GIL 来解决多核并行处理问题。这将允许同一进程中解释器之间的并行处理，但对在解释器之间共享 Python 数据施加了很大的限制。此 PEP 和 PEP 684 都解决了多核并行处理问题，但采用了不同的权衡和技术。在 CPython 中同时实现这两个 PEP 是可行的。

Gilectomy

Gilectomy [20] 是 Larry Hastings 在 CPython 中删除 GIL 的一个项目。与此 PEP 提出的设计类似，Gilectomy 支持同一个解释器中多个线程并行运行（即“自由线程”），并使用细粒度锁定。此 PEP 中的参考实现与 Gilectomy 相比，在单线程性能和可扩展性方面有所改进。

PyParallel

PyParallel [21] 是 Trent Nelson 对 Python 3.3 的概念验证分支，它支持在单个 Python 进程中同时运行多个线程。该分支引入了“并行线程”的概念 - 可以同时运行的线程，而主 Python 线程被挂起。并行线程对主线程创建的对象具有只读访问权限。在并行线程中创建的对象在其创建线程的生存期内存在。对于 HTTP 服务器，这可能对应于请求的生存期。

python-safethread

python-safethread [22] 项目是 Adam Olsen 对 Python 3.0 的一个补丁，用于删除 GIL。该项目的一些方面与此 PEP 提出的设计类似。两者都使用细粒度锁定并优化引用计数，以防对象由同一个线程创建和访问。

Greg Stein 的免费线程补丁

1996 年，Greg Stein 发布了一个针对 Python 1.4 的补丁，该补丁删除了 GIL [23]。该补丁在 Windows 上使用原子引用计数，在 Linux 上使用全局引用计数锁。列表和字典访问受互斥锁保护。该补丁的部分内容已在 CPython 中采用。特别是，该补丁引入了 PyThreadState 结构和正确的每线程异常处理。

Dave Beazley 在 2011 年的一篇博客文章中重新审视了该补丁 [24]。

Jython 和 IronPython

一些替代的 Python 实现，如 Jython [25] 和 IronPython [26] 没有全局解释器锁。但是，它们不支持 CPython 扩展。（这些实现可以与用 Java 或 C# 编写的代码进行交互）。

PyPy-STM

pypy-stm [27] 解释器是 PyPy 的一个变体，它使用软件事务内存。作者报告说，与 PyPy 相比，单线程性能开销在 20%-50% 之间。它与 CPython 扩展不兼容。

为什么不使用并发垃圾收集器？

许多最近的垃圾收集器大多是并发的 - 它们通过允许垃圾收集器与应用程序并发运行来避免长时间的停止世界暂停。那么为什么不使用并发收集器呢？

并发收集需要写屏障（或读屏障）。作者不知道在不实质性破坏 C-API 的情况下向 CPython 添加写屏障的方法。

为什么不使用 PyDict_FetchItem 代替 PyDict_GetItem？

此 PEP 提出了一个新的 API PyDict_FetchItem，其行为类似于 PyDict_GetItem，但返回一个新引用而不是一个借用引用。如 借用引用 中所述，在没有 GIL 的情况下运行时，一些使用借用引用的方法是不安全的，需要用像 PyDict_FetchItem 这样的返回新引用的函数来替换，这些函数返回新引用。

此 PEP 不建议弃用 PyDict_GetItem 和类似的返回借用引用的函数，原因有以下几点

• 许多使用借用引用的方法是安全的，即使在没有 GIL 的情况下运行也是如此。例如，C API 函数通常使用 PyDict_GetItem 从关键字参数字典中检索项目。这些调用是安全的，因为关键字参数字典仅对单个线程可见。
• 我在早期尝试过这种方法，发现用 PyDict_FetchItem 全面替换 PyDict_GetItem 经常会导致新的引用计数错误。在我看来，引入新的引用计数错误的风险通常大于遗漏一个在没有 GIL 的情况下不安全的 PyDict_GetItem 调用的风险。

为什么不使用 PEP 683 永生化？

与 PEP 683 一样，此 PEP 提出了一个 Python 对象永生化方案，但 PEP 使用不同的位表示来标记永生对象。这些方案不能完全相同，因为此 PEP 依赖于偏差引用计数，它有两个引用计数字段而不是一个。

改进的专业化

Python 3.11 版本在更快的 CPython 项目中引入了快速化和专门化，从而大大提高了性能。专门化用更快的变体替换了缓慢的字节码指令 [19]。为了保持线程安全，使用多个线程（并在没有 GIL 的情况下运行）的应用程序只会专门化每个字节码一次，这可能会降低某些程序的性能。有可能支持多次专门化，但这需要更多调查，不在此 PEP 的范围内。

Python 构建模式

此 PEP 引入了一种新的构建模式（--disable-gil），它与标准构建模式不兼容。额外的构建模式增加了 Python 核心开发人员和扩展开发人员的复杂性。作者认为，一个值得追求的目标是将这些构建模式结合起来，并在运行时控制全局解释器锁，可能默认情况下禁用。实现这一目标的路径仍然是一个悬而未决的问题，但可能的一种路径如下所示

1. 2024 年，CPython 3.13 发布，支持 --disable-gil 构建时标志。CPython 有两个 ABI，一个有 GIL，一个没有。扩展作者针对这两个 ABI。
2. 在 2-3 个版本之后（即 2026-2027 年），CPython 发布，GIL 由运行时环境变量或标志控制。GIL 默认情况下启用。只有一个 ABI。
3. 在另外 2-3 个版本之后（即 2028-2030 年），CPython 切换到默认情况下禁用 GIL。仍然可以通过环境变量或命令行标志在运行时启用 GIL。

此 PEP 包含第一步，其余步骤作为悬而未决的问题。在这种情况下，将有一个为期两到三年的时间，扩展作者将针对每个支持的 CPU 架构和 OS 多构建一个 CPython 构建。

集成

参考实现更改了 CPython 中大约 15,000 行代码，并包含了 mimalloc，它也大约有 15,000 行代码。大多数更改对性能不敏感，可以在 --disable-gil 和默认构建中包含。一些宏，例如 Py_BEGIN_CRITICAL_SECTION 在默认构建中将是空操作。作者预计不会有大量 #ifdef 语句来支持 --disable-gil 构建。

针对单线程性能的缓解措施

PEP 中提出的更改将增加 --disable-gil 构建的执行开销，与具有 GIL 的 Python 构建相比。换句话说，它将具有更慢的单线程性能。有一些可能的优化可以减少执行开销，特别是对于仅使用单个线程的 --disable-gil 构建。如果长期目标是拥有单一的构建模式，这些可能是值得的，但是优化选择及其权衡仍然是一个开放的问题。