我的一些笔记,人生感悟、读后感、开箱评测等

0%

GIL

GIL 有什么好处?

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

Python(CPython)为什么存在 GIL?

根据官方 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 影响了性能(比如上面讨论的情况),你可以创建一个独立进程并等待它结束。

打赏一杯咖啡