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，但生态兼容性弱，生产环境慎用