快手面试题：全局解释器锁

题目

详细解释一下Python的GIL。

解答

GIL 是 全局解释器锁（Global Interpreter Lock） 的缩写。它是 CPython（Python 最主流的官方实现）中的一个机制，本质上是一个互斥锁，用于保证同一时刻只有一个线程可以执行 Python 字节码。也就是说，即使在多核 CPU 上，使用 CPython 解释器的 Python 程序也无法真正并行执行多个线程。

为什么会有 GIL？

GIL 的存在主要源于 CPython 的内存管理方式。CPython 使用引用计数来管理内存：每个对象都有一个计数器，记录有多少引用指向它；当引用计数归零时，对象的内存会被自动释放。

如果允许多个线程同时操作同一个对象的引用计数，就会产生竞态条件（race condition），导致引用计数错误（可能过早释放或内存泄漏）。解决这个问题的一种方法是给每个对象都加上细粒度的锁，但这样会大大增加锁的开销，并且容易导致死锁。因此，Python 的设计者选择了一种更简单的方案------在解释器级别加一个全局锁，保证任何时候只有一个线程在执行 Python 代码，从而保证引用计数的线程安全。

这个设计决策可以追溯到 1992 年，当时单核 CPU 还是主流，多线程更多地用于处理 I/O 等待，而不是并行计算。GIL 在当时是一个简单有效的选择。

GIL 的工作原理

当一个 Python 线程要执行字节码时，它必须先获得 GIL。GIL 本身是一个互斥锁，线程获得后开始执行。但为了防止某个线程一直霸占 GIL 导致其他线程饿死，CPython 引入了一个机制：

• 每执行一定数量的字节码指令（默认是 100 条），或者当一个线程遇到 I/O 操作时，当前线程会主动释放 GIL，并通知操作系统进行线程切换。其他等待的线程此时可以竞争 GIL 并开始执行。

• 这个切换是由解释器内部的一个计数器（ticks）控制的，Python 3.2 之后改用了基于时间的机制（每隔 5 毫秒），但原理类似。

值得注意的是，GIL 只在执行 Python 字节码时才需要。当线程执行外部调用（如 C 扩展、系统调用、I/O 操作）时，通常会释放 GIL，这样其他 Python 线程就可以继续运行。这也是为什么 GIL 对 I/O 密集型程序影响较小的原因。

GIL 对多线程的影响

1. CPU 密集型任务

对于需要大量计算的程序（如数学计算、循环、数据处理），多个线程无法利用多核 CPU 的并行优势。因为任何时候只有一个线程在执行，其他线程即使就绪也只能等待。这种情况下，多线程不仅不能加速，反而会因为线程切换带来额外的开销，导致比单线程还慢。

示例：一个死循环的 CPU 计算，用两个线程分别执行，总时间并不会比单线程快，甚至会略慢。

2. I/O 密集型任务

对于涉及大量等待的任务（如网络请求、文件读写、数据库查询），多线程可以很好地发挥作用。因为当线程发起 I/O 操作时，它会释放 GIL，此时其他线程可以继续执行 Python 代码。这样，CPU 可以在等待 I/O 完成的同时做其他工作，提高了整体效率。

示例：多线程下载多个网页，每个线程在等待网络响应时会释放 GIL，其他线程可以继续发送请求或处理已返回的数据。

如何绕过或应对 GIL？

GIL 是 CPython 的特性，但我们可以通过以下方式减轻或避免其限制：

1. 使用多进程（multiprocessing 模块）

multiprocessing 模块会创建多个 Python 进程，每个进程有自己的 GIL，因此可以真正并行执行 CPU 密集型任务。缺点是进程间通信（IPC）比线程间通信开销大，且内存不共享。

2. 使用其他 Python 实现

有些 Python 实现没有 GIL，例如：

• Jython（运行在 Java 虚拟机上）

• IronPython（运行在 .NET 平台上）

• PyPy 的某些版本（如 PyPy-STM 或实验性的无 GIL 分支）

但这些实现通常与 CPython 不完全兼容，或生态支持较弱。

3. 使用 C 扩展

将 CPU 密集型代码用 C 或 C++ 编写，并通过 Python 的 C API 调用。在 C 扩展中，可以手动释放 GIL，从而实现并行。例如，NumPy、Pandas 等科学计算库底层都是 C 实现的，它们在执行数组运算时会释放 GIL，因此即使 Python 线程持有 GIL，也不影响这些库内部的并行计算。

4. 异步编程（asyncio）

对于 I/O 密集型任务，使用 asyncio 可以在单线程内通过事件循环实现高并发，避免了多线程切换的开销。虽然它不能利用多核，但通常比多线程更高效。

5. 协程（gevent/eventlet）

基于 greenlet 的第三方库，通过 monkey-patch 将标准库的阻塞 I/O 变为非阻塞，实现并发效果，本质上也还是在单线程内切换。

GIL 的未来

长期以来，GIL 一直是 Python 社区讨论的焦点。彻底移除 GIL 非常困难，因为它涉及 CPython 内部大量数据结构的线程安全改造，可能会降低单线程性能并增加实现复杂度。

不过，近年来有了新的进展：

• PEP 703 （Making the Global Interpreter Lock Optional in CPython）提出了一种方案，允许在编译 CPython 时选择禁用 GIL，并通过引入"每对象引用计数"等机制保证线程安全。该提案已被接受为"前进方向"，但目前仍处于实验阶段。

• 如果 PEP 703 最终实现并稳定，未来的 CPython 可能会提供一个无 GIL 的构建选项，让开发者根据需要选择。

总结

• GIL 是 CPython 的全局锁，保证同一时刻只有一个线程执行 Python 字节码。

• 历史原因：简化内存管理，避免细粒度锁的复杂性和开销。

• 工作原理：线程必须获取 GIL 才能执行，每执行一段时间或遇到 I/O 会释放。

• 影响：

  • CPU 密集型：多线程无法利用多核，可能更慢。

  • I/O 密集型：多线程仍有效，因为 I/O 时会释放 GIL。

• 应对方法：多进程、C 扩展、异步编程、其他 Python 实现。

• 未来：PEP 703 有望让 GIL 成为可选，但仍需时间。

理解 GIL 对于编写高性能 Python 程序至关重要，尤其是在涉及并发和并行计算的场景中。选择合适的并发模型可以让你避开 GIL 的限制，发挥出硬件的最大潜力。