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