cpython多线程是伪并发，受gil限制：任意时刻仅一个线程执行python字节码；gil保障引用计数与gc线程安全；i/o和c扩展时释放gil实现有效并发，cpu密集型任务则不适用。
Python多线程在CPython中不是真正意义上的并发执行，而是“伪并发”——它能同时存在多个线程，但任意时刻只有一个线程在执行Python字节码。这个限制来自GIL（全局解释器锁），它是CPython解释器的底层机制，不是语言规范，也不是所有Python实现都有的（比如Jython、PyPy部分模式就无GIL）。
什么是GIL：一把保护解释器的“安全锁”
GIL是一把互斥锁，确保同一时间仅有一个线程进入CPython解释器执行Python代码。它的存在不是为了限制性能，而是为了解决两个关键问题：
-
引用计数的线程安全：CPython用引用计数管理内存，多个线程同时增减同一个对象的
ob_refcnt会导致崩溃或内存泄漏；GIL让修改操作串行化，避免加细粒度锁带来的复杂性和开销。 - 垃圾回收（GC）的稳定性：标记-清除等GC过程需遍历所有对象，若与业务线程并发运行，可能误删活跃对象或漏标，GIL保证GC只在线程释放锁后执行。
GIL什么时候释放？决定你能不能“感觉”到并发
GIL不是一直锁死的，它有明确的释放时机，这直接决定了多线程在不同任务中的表现：
-
I/O操作时自动释放：调用
time.sleep()、requests.get()、文件读写、socket收发等，线程会立刻交出GIL，其他线程可立即抢占——这是多线程在爬虫、API调用等场景高效的原因。 -
C扩展执行期间通常释放：像
numpy数组运算、cv2.resize()、hashlib等底层C代码，只要显式释放GIL（绝大多数主流库都做了），就能并行利用多核。 - 定期时间片轮转（约5ms）：即使纯Python计算，CPython也会强制让出GIL，防止某个线程长期霸占；但这不是为加速，而是为响应性——结果往往是频繁切换反而拖慢CPU密集型任务。
多线程“并发”的真实边界在哪里
是否“有效并发”，完全取决于任务类型，不能一概而论：
立即学习“Python免费学习笔记（深入）”；
- IO密集型任务（推荐用多线程）：如发起10个HTTP请求、处理多个文件上传、监听多个socket连接。线程大部分时间在等待，GIL释放频繁，实际是多个线程交替推进，总耗时远低于串行。
- CPU密集型任务（慎用多线程）：如循环计算、图像像素处理、加密解密（纯Python实现）。线程始终持有GIL，4个线程跑下来可能比单线程还慢——因为多了锁竞争和上下文切换开销。
- 混合型任务（看瓶颈在哪）：比如先读文件（IO）、再做计算（CPU）、最后写日志（IO）。若计算占比高，多线程收益有限；若IO占主导，仍可受益。
绕过GIL的常用路径
当遇到CPU密集瓶颈又想保持Python开发效率时，有几种成熟方案：
-
换多进程（
multiprocessing）：每个进程有独立解释器和GIL，天然并行。适合数据分片、批量处理等场景，代价是进程启动开销大、内存不共享、通信需Queue或Pipe。 -
用异步IO（
asyncio）：单线程内协程调度，无GIL争抢，I/O并发能力极强，适合高吞吐网络服务，但要求全栈异步（不能混入阻塞调用）。 -
调用释放GIL的C扩展：用
numpy、scipy、numba.jit(nogil=True)或自写Cython模块，在计算段主动释放GIL，让多线程真正并行跑C代码。
