Python GIL 的存在原因与影响

2026-01-29 00:00:00 作者：舞夢輝影

GIL是CPython为简化引用计数内存管理而设的全局互斥锁，牺牲多线程CPU并行性以保障C扩展兼容与实现简单；Python 3.12仅优化为细粒度锁，未移除GIL。

为什么 CPython 要加 GIL

GIL（Global Interpreter Lock）不是 Python 语言规范的一部分，而是 CPython 解释器实现层面的互斥锁。它的存在主要为了简化内存管理——CPython 的垃圾回收基于引用计数，而引用计数的增减操作必须是原子的。如果没有 GIL，多线程并发修改同一对象的 ob_refcnt 字段会导致计数错误、内存泄漏甚至崩溃。

换句话说，GIL 是用「牺牲并发性」换来了「实现简单性」和「C 扩展兼容性」。它让大量依赖 C API 的第三方库（如 numpy、cv2）无需额外加锁就能安全运行。

GIL 对多线程 CPU 密集型任务的实际影响

在纯计算场景下，GIL 会让多线程几乎无法并行利用多核：

threading.Thread 启动 4 个计算函数，实际仍是轮转执行，总耗时接近单线程 × 4
time.sleep() 或文件 I/O 等阻塞操作会主动释放 GIL，此时其他线程可抢占，所以多线程对 I/O 密集型任务仍有意义
numpy、scipy 等底层用 C 实现的运算，通常会在执行前释放 GIL，因此多线程调用它们能真正并行

验证方式很简单：写一个死循环累加的函数，用 threading 和 multiprocessing 分别跑 4 次，对比 time.time() 差值——前者基本不提速，后者接近 4 倍加速。

绕过 GIL 的常见路径与代价

真要并行 CPU 密集任务，主流做法只有三个，各自有明确取舍：

用 multiprocessing：每个进程有独立解释器和内存空间，天然绕过 GIL；但进程启动开销大、进程间通信（Queue、Pipe）比线程共享变量慢得多，且无法直接传 lambda 或闭包
用 asyncio + 协程：只适用于 I/O 密集场景，对 CPU 密集无效，因为协程仍运行在单线程中，不释放 GIL
换解释器：比如 PyPy（部分场景无 GIL，但不保证）、Jython（JVM 上无 GIL）、Cython 编译关键函数为 C 扩展并在
内部释放 GIL——但开发成本陡增，调试难度上升