python多线程在cpu密集型任务中性能下降，根本原因是cpython的gil强制字节码串行执行；io密集型任务中线程仍高效，因gil会被自动释放；突破gil首选多进程，其次可选协程、c扩展等方案。
Python多线程在CPU密集型任务中性能不升反降，根本原因不是代码写得不好，而是CPython解释器自带的GIL（全局解释器锁）强制串行执行Python字节码。它不阻止你开10个线程，但只允许其中1个真正“干活”，其余都在排队等锁——还白白消耗线程切换成本。
CPU密集型任务：多线程基本无效
GIL的存在意味着：哪怕你有16核CPU，用threading启动8个计算线程，实际仍是单核满载、其余核心空转。实测中，质数判断、斐波那契、矩阵运算等典型计算任务，4线程常比单线程慢5%–20%，就因为锁竞争和上下文切换拖了后腿。
- 典型表现：top命令看到CPU占用率始终卡在~100%，而非接近400%
- 错误信号：time.time()测出多线程耗时更长
- 本质问题：GIL保护的是CPython内部对象模型（如引用计数），无法绕过，也无需“修复”——它是设计取舍，不是bug
IO密集型任务：线程依然好用
网络请求、文件读写、数据库查询这类任务，线程大部分时间在等待响应。此时GIL会被自动释放，其他线程立即接管执行，实现高效并发。
- 例如：用requests发100个HTTP请求，4线程可将总耗时从20秒压到5秒左右
- 注意：不要混用——在IO任务里掺入大量本地计算，会重新触发GIL争抢，拖慢整体
突破GIL的务实路径：优先选多进程
multiprocessing模块是绕过GIL最直接、最稳定的方式。每个进程拥有独立解释器、独立内存、独立GIL，天然支持多核并行。
- 推荐用concurrent.futures.ProcessPoolExecutor，接口与ThreadPoolExecutor一致，替换成本极低
- 数据传递尽量用不可变类型（如tuple、int、str），避免序列化/反序列化开销
- 进程数不宜超过CPU逻辑核心数（可用os.cpu_count()获取），过多反而因调度损耗降低效率
其他可行替代方向
多进程不是唯一解，根据场景可灵活组合：
- 协程（asyncio）：纯IO高并发首选，单线程轻松支撑数千连接，无GIL干扰，内存占用极小
- C扩展或Cython：把计算密集部分用C重写，在C代码中释放GIL，Python层调用，兼顾性能与开发效率
- 第三方解释器（如PyPy）：对某些IO密集场景有优化，但GIL仍存在；Jython/IronPython无GIL，但生态兼容性弱，生产环境慎用
