GIL（Global Interpreter Lock，全局解释器锁）是 Python（尤其是 CPython）中被讨论最多、也最容易被误解的一个机制。它的存在，直接决定了多线程在 CPU 密集型任务中几乎无法加速，但并不影响 IO 密集型任务的并发效果。这一节就把它讲清楚。
GIL 的本质
GIL 是一把互斥锁，由 CPython 解释器在运行时持有。它的规则很简单：任何时刻，只有一个线程可以执行 Python 字节码。即使你的机器有多个 CPU 核心，也只允许一个线程运行 Python 代码。
换句话说，操作系统看到的多个线程，在 Python 层面是串行执行的。你可以同时启动 10 个线程，但同一时间只有一个在做 Python 层面的运算，其余 9 个只能等待。
为什么 CPython 要设计 GIL？
根本原因在于 CPython 的内存管理不是线程安全的。Python 使用引用计数来管理对象的生命周期，每个对象内部都有一个 ob_refcnt 字段。如果没有锁保护，多个线程同时修改同一个对象的引用计数，就会导致内存损坏或程序崩溃。
为所有对象都加细粒度锁，性能开销太大且容易死锁。CPython 开发者选择了一条更简单、安全的路：用一把全局锁，把整个解释器保护起来。在 GIL 的保护下，引用计数的增减可以安全地进行，同时内存分配的临界区也被保护。
注意：Jython（运行在 JVM 上）和 IronPython（运行在 .NET 上）没有 GIL，因为它们依赖底层平台的内存管理。PyPy 也有 GIL，但正在尝试去除。
对多线程性能的实际影响
影响必须分场景讨论：
- CPU 密集型任务（如数值计算、图像处理、大规模循环）：
多线程几乎没有加速效果，甚至因为线程切换的额外开销，会比单线程更慢。
例如，用一个线程计算斐波那契数列耗时 10 秒，开 4 个线程各算一个不同的斐波那契数，总耗时依然在 10 秒以上（甚至更久），因为同一时刻只有一个线程能真正在计算。
- IO 密集型任务（如网络请求、文件读写、数据库查询）：
线程在等待 IO 时，会主动释放 GIL，让其他线程获取锁并执行。此时多线程可以显著减少总等待时间，加速效果明显。
在生产实践中，用 Python 写 Web 服务（Flask、Django 的默认运行模式）就是多线程模式的典型应用：线程 A 等待数据库查询时，线程 B 可以处理另一个 HTTP 请求。
规避 GIL 限制的常用方案
既然 GIL 限制了多线程的 CPU 并行能力，我们可以采用以下方案来真正利用多核：
- 使用多进程：
multiprocessing 模块会启动多个 Python 解释器进程，每个进程有自己的独立 GIL，可以被操作系统调度到不同的 CPU 核心上，实现真正的并行执行。这是 CPU 密集型任务的首选。
- 代价：进程间通信需要序列化数据，开销比线程共享内存大；每个进程独立内存，内存占用较高。
- 使用 C 扩展或 Cython 释放 GIL：
如果你编写 C/C++ 扩展，可以在执行纯计算逻辑时通过宏释放 GIL，让其他 Python 线程能够同时运行。Cython 也支持在特定代码块标记 with nogil: 来释放 GIL，实现并行。
- 使用 PyPy 或其他解释器：
PyPy 也带 GIL，但它的 JIT 编译通常会提高单线程性能，有时能间接“弥补”GIL 的损失。真正的无 GIL 方案目前尚不成熟，但 CPython 社区已经在探索。
- 使用协程处理 IO 并发：
对于 IO 密集型场景，asyncio + async/await 可以用单线程实现高并发，完全绕过 GIL 的影响。
实用建议
- 当你需要同时处理大量网络请求、文件读写、数据库访问时，多线程或协程是合适的，GIL 不是瓶颈。
- 当你需要多核并行计算（训练机器学习模型、大规模矩阵运算、视频处理等），请直接用多进程，不要再纠结多线程为什么慢。
- 很多高性能库（如 NumPy、Pandas 的底层 C 代码）在执行数组运算时会释放 GIL，因此对这些库的操作配合多线程有时也能获得一些加速，但需要具体测试。
理解 GIL，不是为了否定 Python 的多线程，而是为了在正确的地方用对正确的并发模型。这是从 Python 中级向高级迈进的必经一课。