Python多线程在CPU密集型任务中几乎无法提升性能，根本原因是GIL强制单线程执行字节码；I/O密集型任务“看似适合”是因为I/O自动释放GIL，使其他线程可并发执行，实为提高CPU利用率；真正加速需用multiprocessing、numba、Cython或支持GIL释放的C扩展。
Python多线程在CPU密集型任务中几乎无法提升性能，核心原因在于全局解释器锁（GIL）强制同一时刻只有一个线程执行字节码。上下文切换本身开销不大，但GIL导致的线程频繁让出、争抢和阻塞，才是拖慢实际运行的关键。
上下文切换到底花多少时间？
现代操作系统单次线程上下文切换通常在几十纳秒到几微秒量级，对纯计算任务影响极小。但在Python中，由于GIL存在，线程并非“自由调度”：每当一个线程执行约5毫秒（默认ticks，可通过sys.setswitchinterval()调整）或遇到I/O、显式调用time.sleep()等阻塞操作时，就会主动释放GIL，触发调度器选择下一个就绪线程——这个过程叠加了GIL获取失败重试、线程唤醒延迟等额外开销，实际感知延迟远高于纯上下文切换本身。
为什么I/O密集型任务看起来“适合”多线程？
因为I/O操作（如网络请求、文件读写）会自动释放GIL。此时线程挂起，其他线程可立即获得GIL继续执行，形成“伪并行”。这不是线程变快了，而是GIL空闲期被有效利用了。常见误区是认为“多线程加速了I/O”，其实加速的是I/O等待期间的CPU利用率。
- 用requests.get()发HTTP请求时，大部分时间在等响应，GIL已释放
- 用open().read()读大文件可能不释放GIL（取决于底层实现），反而卡住其他线程
- 真正友好的I/O操作需明确支持GIL释放，如socket.recv()、time.sleep()、queue.get()
如何验证你的多线程是否真在并发？
别只看总耗时，要观察线程行为：
立即学习“Python免费学习笔记（深入）”；
- 用threading.enumerate()确认线程数量与预期一致
- 在关键位置加print(threading.current_thread().name, time.time())粗略看执行交错
- 更准确：用perf record -e sched:sched_switch python script.py（Linux）分析内核调度事件
- 对比threading和concurrent.futures.ThreadPoolExecutor的行为差异——后者自带任务队列和复用机制，减少反复创建开销
替代方案比“硬扛GIL”更有效
若任务本质是CPU密集型（如数值计算、图像处理、加密解密），应绕过线程，改用：
- multiprocessing：每个进程有独立Python解释器和GIL，真正并行
- numba.jit或Cython：编译热点代码，运行时直接绕过GIL
- asyncio：适用于高并发I/O（如万级HTTP请求），单线程内协程切换开销远低于线程上下文切换
- 调用已释放GIL的C扩展库，如numpy多数运算、PIL.Image处理等
