Python GIL：为什么Python多线程不是真正的并行？ – wiki基地

深入理解 Python GIL：为什么多线程无法实现真正的并行？

Python 作为一种高级的、解释型的、通用的编程语言，因其简洁易读的语法和强大的库生态而广受欢迎。在处理并发任务时，开发者自然会想到使用多线程来提高效率。然而，许多 Python 开发者在使用多线程处理计算密集型任务时，会发现性能并没有如预期般提升，甚至可能下降。这背后的“罪魁祸首”，正是 Python 的全局解释器锁（Global Interpreter Lock），简称 GIL。

本文将深入探讨 GIL 是什么、它为什么存在、它是如何工作的，以及为什么它会导致 Python 的多线程在处理 CPU 密集型任务时无法实现真正的并行。同时，我们也会探讨在面对并发需求时，Python 提供的其他解决方案。

1. 并发 vs. 并行：理解基本概念

在讨论 GIL 之前，区分“并发”（Concurrency）和“并行”（Parallelism）这两个概念至关重要：

并发 (Concurrency): 指的是多个任务“看起来”在同时进行。在单核处理器上，并发是通过时间片轮转实现的，即 CPU 在不同任务之间快速切换，让每个任务执行一小段时间，从而给人一种同时进行的错觉。在多核处理器上，并发既可以发生在同一个核心上（通过时间片），也可以跨不同的核心。并发强调的是任务之间的交替执行或重叠执行。
并行 (Parallelism): 指的是多个任务在同一时刻真正地同时进行。这只有在多核处理器或多处理器系统上才能实现，不同的任务在不同的 CPU 核心上同时执行。并行强调的是物理上的同步执行。

简单来说，并发是“同时处理多个任务的能力”，而并行是“同时执行多个任务的能力”。Python 的多线程在 I/O 密集型任务中表现良好，实现了并发；但在 CPU 密集型任务中，由于 GIL 的限制，很难实现真正的并行。

2. 进程 vs. 线程：Python 中的并发模型

在 Python 中，实现并发主要有两种方式：多进程（Multiprocessing）和多线程（Threading）。

进程 (Process): 一个进程是程序在操作系统中一次执行的实例。每个进程都有自己独立的内存空间、数据栈以及其他资源。进程之间的数据通信相对复杂，通常需要通过进程间通信（IPC）机制（如管道、队列、共享内存等）。创建一个进程的开销较大。
线程 (Thread): 一个线程是进程内的执行单元。同一进程中的所有线程共享该进程的内存空间、文件句柄等资源。线程之间的通信相对容易（直接访问共享数据），但需要注意同步问题（如竞态条件）。创建一个线程的开销比进程小。

理想情况下，对于计算密集型任务，我们希望利用多核 CPU 的能力，让多个任务在不同的核心上并行执行，这时多进程是更好的选择。对于 I/O 密集型任务（如网络请求、文件读写），任务大部分时间都在等待 I/O 完成，此时多线程更适合，因为线程在等待 I/O 时可以释放 CPU，让其他线程有机会执行，从而提高整体的 I/O 并发能力。

然而，GIL 的存在改变了多线程在 CPU 密集型场景下的表现。

3. 什么是 Python GIL？

GIL，全称 Global Interpreter Lock（全局解释器锁），是 CPython（Python 官方实现的解释器）中的一个机制。它是一个互斥锁（Mutex），用于保护对 Python 对象访问，防止多个原生线程同时执行 Python 字节码。

这意味着，即使在多核处理器上，一个 Python 进程中同时只能有一个线程持有 GIL，从而执行 Python 字节码。当一个线程在执行 Python 代码时，它必须先获取 GIL；当该线程进行 I/O 操作、时间片用尽或遇到其他需要释放 GIL 的情况时，它会释放 GIL，允许其他线程获取并执行。

GIL 不是 Python 语言规范的一部分，而是 CPython 解释器的一个实现细节。其他 Python 解释器，如 Jython（基于 Java）和 IronPython（基于 .NET），就没有 GIL。然而，CPython 是目前使用最广泛的 Python 解释器。

4. GIL 是如何工作的？

GIL 的工作机制可以概括为以下几点：

获取 GIL： 任何执行 Python 字节码的线程都必须先获取 GIL。
持有 GIL： 一旦线程获取了 GIL，它就可以执行 Python 字节码。在它执行期间，其他尝试执行 Python 字节码的线程会被阻塞，直到 GIL 被释放。
释放 GIL： 持有 GIL 的线程会在以下几种情况下释放 GIL：
- 遇到 I/O 操作： 当线程执行到会阻塞等待 I/O 的操作时（如文件读写、网络请求 socket.recv() 等），它会主动释放 GIL，允许其他线程执行。一旦 I/O 操作完成，该线程会尝试重新获取 GIL。
- 达到一定的时间片： CPython 解释器有一个机制，会强制持有 GIL 的线程在执行一定数量的字节码指令或达到一定的时间间隔（在 Python 3.2 之后，这个机制基于一个定时器，默认为 5 毫秒）后，暂时释放 GIL，以便其他线程有机会获取 GIL 执行。这个机制是为了防止一个 CPU 密集型线程长时间霸占 GIL，导致其他线程（包括 I/O 密集型线程）饿死。
- 线程完成或退出： 当线程执行完毕或异常退出时，会释放其持有的 GIL。
- 显式释放/获取： 某些底层的 C 扩展代码在执行长时间任务时，可以显式地释放和获取 GIL（通过 Py_BEGIN_ALLOW_THREADS 和 Py_END_ALLOW_THREADS 宏）。

这种机制确保了在任何时刻，只有一个线程在解释器层面执行 Python 字节码，从而简化了内存管理（特别是引用计数）等解释器内部操作的复杂性。

5. GIL 为什么存在？它的历史原因

GIL 最初的设计是为了简化 CPython 解释器中内存管理的实现。CPython 使用引用计数来管理内存：当一个对象的引用计数变为零时，该对象占用的内存就会被释放。

在多线程环境中，如果多个线程可以同时访问和修改同一个对象的引用计数，就会出现竞态条件，导致引用计数不准确，进而引发内存泄漏（引用计数永远不为零，但对象不再使用）或程序崩溃（引用计数变为零但对象仍在被使用）。

引入 GIL 是一种相对简单且高效的方式来解决这个问题。通过确保任何时候只有一个线程执行 Python 字节码，CPython 避免了对引用计数等解释器核心数据结构进行复杂的细粒度锁定，大大简化了 CPython 的实现。同时，这也方便了 C 扩展模块的开发，因为 C 扩展的作者不需要自己处理复杂的线程同步问题，只需假定在 C 扩展代码执行时，Python 解释器的内部状态是安全的。

尽管有关于移除 GIL 的持续讨论和尝试，但由于要保持向后兼容性、确保 C 扩展的正确性以及避免引入新的性能瓶颈（尤其是在单线程或 I/O 密集型场景下），移除 GIL 是一项非常复杂的任务。

6. 为什么 GIL 阻止了真正的并行？

现在回到核心问题：为什么 GIL 会阻止 Python 多线程在多核 CPU 上实现真正的并行？

正如 GIL 的工作原理所述，它是一个全局锁。这意味着即使你的计算机有多个 CPU 核心（例如 4 核、8 核），并且你启动了多个 Python 线程，在任何一个瞬间，只有一个线程能够获得 GIL 并执行 Python 字节码。

考虑一个 CPU 密集型任务（例如对大量数据进行复杂的数学计算）。如果你创建了 4 个线程，并让它们同时执行这个任务，在没有 GIL 的情况下，这 4 个线程可以分别在 4 个不同的 CPU 核心上并行运行，理论上速度可以提升接近 4 倍（忽略线程创建、调度等开销）。

然而，由于 GIL 的存在，这 4 个线程必须轮流获取 GIL 才能执行。线程 A 获取 GIL 执行一段时间，然后释放；线程 B 获取 GIL 执行一段时间，然后释放；线程 C、D 也是如此。实际上，这 4 个线程并没有真正地在同一时刻并行执行 Python 字节码，而是在同一个 CPU 核心（或者不同的核心，但同一时刻只有一个核心在执行 Python 字节码）上进行上下文切换，轮流执行。

在 CPU 密集型任务中，线程的主要工作是执行计算，它们很少会主动释放 GIL（除非达到时间片阈值）。频繁的 GIL 获取和释放、线程上下文切换本身也会带来额外的开销。因此，对于 CPU 密集型任务，使用 Python 多线程不仅无法利用多核优势实现并行，反而可能因为 GIL 的竞争和切换开销，导致总的执行时间比单线程执行更长。

总结来说，GIL 就像一个守门的卫士，站在 Python 解释器的门口。无论你有多少个工人（线程）想要进入工厂（CPU 核心）工作，卫士一次只放一个人进去。这导致所有工人都只能排队等待进入，而无法同时在工厂里工作。

7. GIL 对不同类型任务的影响

理解 GIL 对不同类型任务的影响是编写高效 Python 并发代码的关键：

I/O 密集型任务： 对于这类任务，线程大部分时间都花在等待外部资源（如网络响应、磁盘读写）上。当线程执行 I/O 操作时，它会主动释放 GIL。这样，即使某个线程被阻塞，其他线程可以获取 GIL 并继续执行，从而提高了整体的并发度。例如，同时下载多个文件时，使用多线程可以显著提高效率，因为在一个线程等待下载数据时，另一个线程可以开始下载或处理已下载的数据。GIL 对 I/O 密集型任务的并发影响较小，甚至有助于并发。
CPU 密集型任务： 对于这类任务，线程主要在执行计算，很少主动释放 GIL。线程只有在达到时间片阈值时才可能释放 GIL。在多核系统上，多个 CPU 核心闲置，因为它们都在等待同一个 GIL 被释放。如前所述，这无法实现并行，反而可能引入额外的开销。例如，使用多线程对一个大型矩阵进行计算，性能可能不如单线程。GIL 对 CPU 密集型任务的并行影响极大，使其难以并行。

8. 如何在 Python 中绕过 GIL 实现并行？

尽管 GIL 限制了多线程的并行能力，Python 仍然提供了其他工具来实现真正的并行或高效的并发：

多进程 (Multiprocessing)：
这是解决 GIL 对 CPU 密集型任务限制的最常用方法。multiprocessing 模块创建的是独立的进程，每个进程都有自己的 Python 解释器和独立的 GIL。因此，不同的进程可以在不同的 CPU 核心上真正地并行执行 Python 字节码。
缺点：进程创建的开销比线程大；进程间数据通信需要通过 IPC 机制，比线程间共享内存复杂；内存消耗通常比多线程高。
适用场景：CPU 密集型任务。
异步编程 (Asyncio)：
Python 的 asyncio 模块提供了一种基于协程（Coroutine）的异步编程框架。它通过事件循环（Event Loop）和协程的协作式多任务机制，在单线程（或少量线程，用于处理阻塞 I/O）中实现高并发。协程在遇到 await 等待异步操作时，会主动让出控制权，让事件循环去运行其他准备好的协程。
asyncio 主要用于 I/O 密集型任务，因为 await 通常用在异步 I/O 操作前。它实现了高效的并发，但不是真正的并行（因为它通常在单线程中运行）。对于 CPU 密集型任务，一个长时间运行的协程会阻塞整个事件循环，因此不适合直接在主事件循环中执行。如果需要在 asyncio 中执行 CPU 密集型任务，通常需要将其放到单独的进程或线程池中执行（例如使用 loop.run_in_executor）。
适用场景：高并发的 I/O 密集型任务。
使用 GIL 友好的库 (C Extensions)：
许多科学计算库（如 NumPy、SciPy）和数据处理库（如 Pandas）的底层是用 C、C++ 或 Fortran 实现的。这些库在执行计算密集型操作时，通常会主动释放 GIL，然后在底层进行真正的并行计算（例如使用 OpenMP 或其他并行库）。当计算完成后，它们会重新获取 GIL。因此，在使用这些库执行计算密集型任务时，即使在多线程环境或单线程环境中使用这些库，底层计算部分是可以实现并行的，不会受到 GIL 的限制。
适用场景：利用已有的、底层实现释放 GIL 的高性能计算库。
替代的 Python 解释器：
Jython 和 IronPython 没有 GIL，它们依赖于 Java 或 .NET 平台的原生多线程机制。使用这些解释器可以在多线程中实现并行。然而，它们的缺点是与 CPython 的兼容性（尤其是 C 扩展库）可能较差。PyPy 是另一个高性能的 Python 解释器，它也在尝试改进 GIL 的实现，甚至有无 GIL 的实验性分支，但这些还在发展中。
适用场景：对 CPython 兼容性要求不高，或特定平台开发的场景。

9. 关于 GIL 移除的讨论和尝试

多年来，社区一直有人尝试移除或改进 GIL。比较著名的尝试包括：

Free Threading/No-GIL Python: 有多个实验性的 Python 分支试图移除 GIL，但往往面临性能下降（尤其对单线程或 I/O 密集型代码）和破坏 C 扩展兼容性的挑战。
PEP 703 (Making the Global Interpreter Lock Optional in CPython): 这是近年来比较活跃的一个提案，旨在让 CPython 中的 GIL 成为可选的。如果成功，用户将可以选择构建一个无 GIL 的 Python 解释器，从而在多线程中实现并行。这个提案仍在积极开发和审查中，面临许多技术挑战，例如如何安全高效地处理引用计数等。

移除 GIL 是一个极其复杂的工程，因为它涉及到对 CPython 核心架构的根本性改变，需要平衡并行性、单线程性能、内存使用以及与现有 C 扩展的兼容性等多个目标。即便未来某个版本成功移除了 GIL，现有的大量 C 扩展也可能需要修改才能在新环境中安全工作。

10. 总结

Python 的全局解释器锁（GIL）是 CPython 解释器的一个实现细节，它确保了在任何时刻，一个 Python 进程中只有一个线程可以执行 Python 字节码。GIL 最初是为了简化 CPython 的内存管理（特别是引用计数）而引入的，并简化了 C 扩展的开发。

GIL 的存在导致 Python 的多线程在处理 CPU 密集型任务时无法实现真正的并行，即使在多核处理器上也是如此。这限制了多线程在这一领域的性能提升。然而，对于 I/O 密集型任务，线程在等待 I/O 时会释放 GIL，允许多个线程并发执行，从而提高了效率。

理解 GIL 对不同任务类型的影响至关重要。对于需要利用多核实现并行计算的 CPU 密集型任务，应优先考虑使用 multiprocessing 模块。对于需要处理大量并发连接或等待的 I/O 密集型任务，多线程 (threading) 或异步编程 (asyncio) 是更好的选择。此外，许多高性能的第三方库（如 NumPy）通过在底层 C 代码中释放 GIL 来实现并行。

虽然关于移除 GIL 的讨论和尝试一直在进行，但它仍然是当前标准 CPython 解释器的重要组成部分。作为 Python 开发者，了解 GIL 的存在和影响，并选择合适的并发工具来解决具体问题，是编写高效、健壮的 Python 程序的关键。

希望这篇文章能帮助您深入理解 Python GIL 及其对多线程并行性的影响！