Python 线程真的并发了吗？从 GIL 执行窗口说起
GIL是CPython中限制同一时刻仅一个线程执行字节码的互斥锁，导致CPU密集型任务无法多核并行；I/O操作会自动释放GIL，使线程在I/O密集场景下呈现并发效果。
Python 的线程在 CPython 解释器下不是真正的并发执行，而是协作式地轮流获得 GIL（全局解释器锁）的执行窗口——这决定了它无法利用多核 CPU 并行执行 CPU 密集型任务。
GIL 是什么？它怎么控制线程执行
GIL 是 CPython 解释器内部的一把互斥锁，同一时刻只允许一个线程执行 Python 字节码。即使你启用了 10 个线程，它们也必须排队等待获取 GIL 才能运行。
- 每个线程默认最多执行约 5ms（或 100 个字节码指令，具体取决于 Python 版本）后主动释放 GIL，让出执行权
- I/O 操作（如文件读写、网络请求、
time.sleep()）会触发线程自动释放 GIL，此时其他线程可抢占执行 - 纯计算循环（比如大数组累加、递归阶乘）几乎不释放 GIL，导致其他线程长期阻塞
为什么线程看起来“像在并发”
因为 GIL 的切换足够快，加上 I/O 等待期间的让出，使得多个线程在宏观上呈现“同时进行”的效果，尤其在 I/O 密集型场景中体验良好。
- 例如：同时发起 5 个 HTTP 请求，每个请求等待响应时释放 GIL，其余线程可继续发请求或处理前序响应
- 但若换成计算斐波那契数列（无 I/O），5 个线程总耗时≈1 个线程的 5 倍，毫无加速效果
想真正并发？得绕开 GIL
对 CPU 密集型任务，需用不依赖 CPython GIL 的方案：
-
多进程（
multiprocessing）：每个进程有独立解释器和 GIL，天然并行，适合数据独立、可序列化的任务 -
异步 I/O（
asyncio）：单线
程内协程调度，避免线程开销，I/O 密集型效率更高
-
调用 C 扩展或使用
numba/cython：在 C 层释放 GIL 后做计算，再安全回调 Python - 换解释器：如 Jython（JVM）、IronPython（.NET）无 GIL，但生态和兼容性受限
一个小实验帮你确认 GIL 行为
运行以下代码，观察 CPU 使用率和耗时：
（注：实际运行时请取消注释并替换为你的测试函数）import threading import timedef cpu_bound_task():
模拟纯计算：不触发 I/O，GIL 不易释放
s = 0 for i in range(10**7): s += i * i return s单线程
start = time.time() cpu_bound_task() print("单线程耗时:", time.time() - start)
4 线程（实际仍是串行）
threads = [threading.Thread(target=cpu_boundtask) for in range(4)] start = time.time() for t in threads: t.start() for t in threads: t.join() print("4 线程耗时:", time.time() - start)
你会发现：4 线程版本耗时接近单线程的 4 倍，且 CPU 占用基本不超 100%，这就是 GIL 在起作用。
