Python Web学习笔记之为什么设计GIL

GIL（global interpreter lock），全局解释器锁，是很多编程语言实现中都具有的特性，由于它的存在，解释器无法实现真正的并发。它也是 Python 中经常讨论的话题之一。

Python 作为编程语言存在多个具体实现，包括最常用的 CPython、超集 Cython、.NET 平台的 IronPython、JVM 上的 Jython，R 语言实现的 RPython、JIT 版本的 PyPy 等等。这里我们只讨论最常用的、官方的 CPython 实现。

GIL 有什么好处？

简单来说，它在单线程的情况更快，并且在和 C 库结合时更方便，而且不用考虑线程安全问题，这也是早期 Python 最常见的应用场景和优势。

根据官方 wiki，CPython 内存管理不是线程安全的，因此需要 GIL 来保证多个原生线程不会并发执行 Python 字节码。

GIL 的存在一直是富有争议的，它导致 CPython 程序无法真正利用现代操作系统的多进程特性。需要注意的是，对于 I/O 图形处理、NumPy 数学计算这样的耗时操作都发生在 GIL 之外，实际上基本不受影响，真正受影响的都是 CPython 字节码的执行，GIL 会导致性能瓶颈的出现。

Python 采用 GIL 而非管理锁出于以下原因：

单线程情况下更快。
瓶颈在于 I/O 的多线程环境下更快。
CPU 耗时操作发生在 C 库调用上时更快。
编写 C 扩展会更容易：除法你手动指定，否则不会发生 Python 线程切换的问题。
封装 C 库变得更容易，因为不需要考虑线程安全问题。如果该库不是线程安全的，你只需要保证调用时 GIL 是锁定的。

GIL 可以被 C 扩展释放，Python 标准库会在每次 I/O 阻塞结束后释放 GIL，因此 GIL 不会对 I/O 服务器产生很大的性能影响。因此你可以 fork 进程或者创建多线程来创建网络服务器处理异步 I/O，GIL 在这种情况下并没有影响。

很多 C 或者 Fortran 编写的数值解析库（numerical libraries）也可以使用类似的方法释放 GIL。在 C 扩展等待 FFT 完成时，解释器可能正在执行其它线程，GIL 在这种情况下相比精良设计的锁解构更简单也更高效。数值解析的部分都是这样的解构，NumPy 扩展会在不需要时及时释放 GIL。

实际上，在很多时候多线程对于服务器程序来说都不是一个好注意。对于低负载程序，fork 多进程更简单更清晰，对于高负载程序，异步 I/O 或者事件驱动更加高效（比如使用 Twisted 框架）。或许，使用多线程的唯一合理解释在于 Windows 上没有 os.fork 。

总之，只有在使用纯 Python 做 CPU 密集运算时 GIL 会是问题。不过你可以使用多进程或者消息传递（比如 mpi4py）来替代，并得到更清晰的架构。此外，Python 还有 processing 这个库可供选择，它提供了和 threading 相同的接口，（比如你可以使用 processing.Process 来代替 threading.Thread。）

如果没有 GIL 的话，多线程可以提供更迅速的 GUI 反应，如果 GIL 影响了性能（比如上面讨论的情况），你可以创建一个独立进程并等待它结束。

整理自 StackExchange 高票回答 Why Was Python Written with the GIL?。