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

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

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

GIL 给 Python 中利用并行性带来的挑战经常出现在强化学习中。NetHack Learning Environment 的作者、Inflection AI 的技术人员 Heinrich Kuttler 写道：

强化学习的最新突破，例如在 Dota 2、StarCraft 和 NetHack 上，都依赖于使用异步 Actor-Critic 方法并行运行多个环境（模拟游戏）。Python 中简单的多线程实现由于 GIL 竞争而无法扩展到几个并行环境之外。多进程，通过共享内存或 UNIX 套接字进行通信，增加了很大的复杂性，实际上排除了从不同工作进程与 CUDA 交互的可能性，严重限制了设计空间。

DeepMind 强化学习团队的软件工程师 Manuel Kroiss 描述了 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 连接。自然地，我们从多进程包开始，但在某个时候，很明显大部分 CPU 时间都消耗在数据处理阶段之间的数据传输上，而不是数据处理本身。基于 GIL 的 CPython 多线程实现也是死路一条。当我们发现 Python 的“nogil”分支时，一个人只用了不到半个工作日就调整了代码库以使用该分支，结果令人惊讶。现在我们可以专注于数据采集系统开发，而不是微调数据交换算法。

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

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

我想更好地了解当前的多线程情况，所以我重新实现了 HMMER 的一部分，HMMER 是多序列比对的标准方法。我选择这种方法是因为它既强调单线程性能（评分）又强调多线程性能（搜索序列数据库）。当使用八个线程时，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 上下文（与进程内的线程不同）。

scikit-learn 开发者、Inria 软件工程师 Olivier Grisel 描述了在 scikit-learn 相关库中不得不绕过 GIL 如何导致更复杂和令人困惑的用户体验：

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

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

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

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

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

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

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

在 PyTorch 中，Python 通常用于协调约 8 个 GPU 和约 64 个 CPU 线程，对于大型模型，可扩展到 4k 个 GPU 和 32k 个 CPU 线程。虽然繁重的工作是在 Python 之外完成的，但 GPU 的速度使得即使是 Python 中的协调也无法扩展。由于 GIL，我们最终经常使用 72 个进程而不是一个。在这种情况下，日志记录、调试和性能调优的难度增加了几个数量级，不断导致开发人员生产力下降。

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

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

即使是 GPU 密集型工作负载也经常包含 CPU 密集型组件。例如，计算机视觉任务通常在数据输入管道中需要多个“预处理”步骤，如图像解码、裁剪和调整大小。这些任务通常在 CPU 上执行，并可能使用 Pillow 或 Pillow-SIMD 等 Python 库。有必要在多个 CPU 核心上运行数据输入管道，以确保 GPU “喂饱”数据。

GPU 性能相对于单个 CPU 核心的提升使得多核性能变得更加重要。要使 GPU 保持完全占用越来越困难。为此，需要高效利用多个 CPU 核心，尤其是在多 GPU 系统上。例如，NVIDIA 的 DGX-A100 拥有 8 个 GPU 和两个 64 核 CPU，以确保 GPU “喂饱”数据。

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

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

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”（表示“threading”）。

禁用 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 堆和分配使得像字典这样的集合通常可以在只读操作期间避免获取锁。这将在集合线程安全部分详细描述。

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 对象；它不应用于分配缓冲区、存储或其他非 PyObject 的数据结构。

本 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 仅依赖于追踪垃圾回收器，那么该方案可能就没有必要了，因为追踪垃圾回收器已经以所需的方式推迟了回收。这并不能“解决”扩展问题，而是将许多挑战转移到了垃圾回收器实现上。

多进程

多进程库允许 Python 程序启动并与 Python 子进程通信。这允许并行化，因为每个子进程都有自己的 Python 解释器（即每个进程有一个 GIL）。多进程存在一些显著的限制。进程间通信受限：对象通常需要序列化或复制到共享内存。这会引入开销（由于序列化）并使基于多进程构建 API 变得复杂。启动子进程也比启动线程更昂贵，特别是使用“spawn”实现时。由于 Python 重新初始化，启动一个线程大约需要 ~100 µs，而启动一个子进程大约需要 ~50 ms (50,000 µs)。

最后，许多 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 支持同一解释器中并行运行多个线程（即“自由线程”）并使用细粒度锁定。与 Gilectomy 相比，本 PEP 中的参考实现在单线程性能和可伸缩性方面有所改进。

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_GetItem 而支持 PyDict_FetchItem？

本 PEP 提出了一个新的 API PyDict_FetchItem，其行为类似于 PyDict_GetItem，但返回的是一个新引用而不是借用引用。如 借用引用 中所述，一些在有 GIL 的情况下安全的借用引用 的使用，在没有 GIL 的情况下是不安全的，需要被返回新引用的函数（如 PyDict_FetchItem）替换。

本 PEP 并未提议弃用 PyDict_GetItem 和其他返回借用引用的类似函数，原因有几个：

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

为什么不使用 PEP 683 不朽化？

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

改进的专业化

Python 3.11 版本引入了快速化和专门化，作为“更快 CPython”项目的一部分，显著提高了性能。专门化用更快的变体替换慢速字节码指令 [19]。为了保持线程安全，使用多线程（且在没有 GIL 的情况下运行）的应用程序只会对每个字节码进行一次专门化，这可能会降低某些程序的性能。支持多次专门化是可能的，但这需要更多研究，并且不属于本 PEP 的一部分。

Python 构建模式

本 PEP 引入了一种新的构建模式 (--disable-gil)，它与标准构建模式不兼容 ABI。额外的构建模式增加了 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 架构和操作系统额外构建一个 CPython。

集成

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

单线程性能的缓解措施

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