GIL导致Python多线程在计算密集型任务中无法提速，因其强制串行执行字节码；它仅在I/O、sleep或字节码计数器检查时释放，而纯计算循环几乎不触发释放，造成线程频繁争锁与切换，实际性能接近单线程。
Python 多线程在计算密集型任务中无法提速，根本原因就是 GIL 强制串行执行——它不是“慢”，而是根本不让多个线程同时跑 Python 字节码。
为什么 GIL 不会在计算过程中释放？
CPython 在纯计算循环（比如 for i in range(10**7)、数值累加、递归调用）中几乎不主动释放 GIL。它只在以下几种情况才可能让出：
- I/O 操作（
open()、requests.get()、socket.recv()）时自动释放 - 调用
time.sleep()等明确让出控制权的函数 - 执行固定数量字节码后被解释器强制检查（默认约 100 条，可通过
sys.setswitchinterval()调整，但对 CPU 密集型任务收效甚微）
计算密集型代码不触发前两类条件，第三类切换又带来额外上下文开销，结果就是：线程轮流上锁 → 执行一小段 → 切换 → 再排队等锁 → 整体耗时接近单线程 × 线程数。
threading 和 multiprocessing 的本质区别在哪？
关键不在“线程 vs 进程”这个表层概念，而在内存与锁的归属：
立即学习“Python免费学习笔记（深入）”；
Claw Code Suite (Python-Only Edition)
下载
仅使用 Python 将 Claw Code 虚拟化框架与 OpenClaw 集成，提供 184 种工具和 200 多条命令，用于安全分析和代码质量...
-
threading：所有线程共享同一块内存、同一个GIL、同一个解释器状态 → 锁是全局瓶颈 -
multiprocessing：每个进程有独立内存空间、独立 Python 解释器、独立GIL→ 不存在跨进程的锁竞争，天然并行
注意：multiprocessing 启动开销大、进程间通信（IPC）成本高，不适合高频小任务；但它对长时间运行的 CPU 计算，效果立竿见影。
哪些“看似多线程”的场景其实绕过了 GIL？
不是所有调用 Python 函数的代码都受 GIL 约束。以下情况会实际释放 GIL：
- 调用底层 C 扩展时显式释放了锁，例如
numpy.dot()、cv2.threshold()、zlib.compress() - 使用
numba.jit(nopython=True)编译的函数，在纯数值计算路径中不进入 Python 解释器 - 调用标准库中明确标注 “releases the GIL” 的 I/O 或计算函数（如
array.array.extend()、io.BytesIO.write()）
这类调用本身仍是多线程，但真正耗时的计算部分已脱离 GIL 控制——所以它们能提速，不是因为线程变强了，而是因为“干活的人”暂时不用排队等锁了。
真正容易被忽略的是：GIL 的存在不是 bug，而是 CPython 内存模型（引用计数）与线程安全之间做的硬性取舍。想靠改写 threading 代码来突破它，注定徒劳；必须换执行单元（进程）、换计算载体（C 扩展），或者换解释器（如 PyPy 的 STM 实验性支持，或 Jython）。
