Python 的 GIL（Global Interpreter Lock，全局解释器锁）是 CPython 解释器的核心机制，它确保同一时刻只有一个线程执行 Python 字节码。这意味着——即使在多核 CPU 上，纯 Python 的多线程程序也无法真正并行执行 CPU 密集型任务，性能不会随线程数增加而提升，甚至可能因线程切换开销而下降。
GIL 的作用与存在原因
GIL 并非设计缺陷，而是 CPython 为简化内存管理（尤其是引用计数）所采取的权衡策略。它避免了多线程同时修改对象引用计数导致的竞争条件，降低了实现复杂度和潜在 bug 风险。但代价是：它成了 CPU 密集型多线程的天然瓶颈。
- 所有 Python 字节码执行都必须先获取 GIL；
- 线程在 I/O 操作、sleep 或部分 C 扩展调用时会主动释放 GIL；
- CPython 会在执行约 100 个字节码指令后强制切换线程（称为“检查点”），但切换不等于并行——新线程仍需争抢 GIL。
CPU 密集型 vs I/O 密集型场景表现差异
多线程在两类任务中受 GIL 影响截然不同：
- CPU 密集型（如数值计算、循环处理、加密解密）：多个线程实质串行执行，总耗时接近单线程，增加线程数反而引入调度和锁竞争开销，性能不升反降；
- I/O 密集型（如网络请求、文件读写、数据库查询）：线程在等待 I/O 时释放 GIL，其他线程可立即运行，此时多线程能显著提升吞吐量，体现并发优势。
绕过 GIL 的常见实践方案
若需真正并行处理 CPU 密集任务，不能依赖 threading，而应考虑以下替代方式：
立即学习“Python免费学习笔记（深入）”；
- 使用 multiprocessing 模块：启动独立进程，每个进程拥有自己的 Python 解释器和 GIL，天然绕过限制；适合可拆分、数据传递成本可控的任务；
- 调用释放 GIL 的 C/C++ 扩展：如 NumPy、SciPy、Pandas 中的多数计算函数，在底层 C 实现中会主动释放 GIL，允许多线程并行调用；
- 改用无 GIL 的 Python 实现：如 Jython（JVM）、IronPython（.NET），或正在快速发展的 PyPy（部分模式支持无 GIL，但尚未默认启用）；
- 异步编程（asyncio）：虽不解决 CPU 并行问题，但在高并发 I/O 场景下比多线程更轻量、高效，且不涉及 GIL 争抢。
如何判断你的代码是否受 GIL 制约？
简单实测比理论分析更可靠：
- 写一个纯计算函数（如计算 1000 万次平方根），分别用 1 个线程、4 个线程、8 个线程运行，观察总耗时是否基本不变甚至变长；
- 用 threading.active_count() 和 time.perf_counter() 对比实际 CPU 时间与挂钟时间，若 CPU 时间远小于挂钟时间，说明大量时间花在等待（可能是 GIL 竞争或 I/O）；
- 借助 py-spy 或 perf 工具采样线程状态，查看是否频繁阻塞在 PyEval_AcquireThread 等 GIL 相关函数上。
