Python 多线程不适合 CPU 密集任务，核心原因是 全局解释器锁（GIL） 的存在——它强制同一时刻只有一个线程执行 Python 字节码，即使在多核 CPU 上，也无法真正并行执行计算密集型代码。
CPU 密集任务会被 GIL 串行化
GIL 是 CPython 解释器为内存管理安全而加的一把“独占锁”。当一个线程在做纯计算（如循环累加、矩阵运算、加密解密）时，它会一直持有 GIL，其他线程只能等待。结果是：多线程跑 CPU 密集任务，耗时几乎和单线程一样，甚至更慢（因线程切换开销）。
- 例如：用 4 个线程各自计算 1 亿次平方和，总耗时 ≈ 单线程跑 4 次的耗时，不是 1/4
- 实际性能测试中，4 线程 CPU 密集任务往往比单线程慢 10%~20%
多线程真正擅长的是 I/O 密集型任务
当线程遇到 I/O 操作（如文件读写、网络请求、数据库查询），会自动释放 GIL，让其他线程运行。此时多线程能显著提升吞吐量。
- 比如同时发起 10 个 HTTP 请求，用多线程可大幅缩短总等待时间
- 因为大部分时间在等网络响应，CPU 是空闲的，GIL 释放后其他线程就能上
替代方案：用多进程绕过 GIL
multiprocessing 模块为每个进程启动独立的 Python 解释器实例，每个都有自己的 GIL 和内存空间，天然支持 CPU 并行。
立即学习“Python免费学习笔记（深入）”；
- 适合科学计算、图像处理、批量数据转换等场景
- 注意进程间通信成本比线程高，数据需序列化（如用
Queue或Manager） - 简单替换：把
threading.Thread换成multiprocessing.Process，或用Pool管理进程池
其他可行选择
- 使用非 GIL 限制的 Python 实现：如 Jython（Java 平台）、IronPython（.NET），但生态和兼容性受限
- 将瓶颈函数用 C/C++/Rust 重写并封装为扩展：调用时可释放 GIL，获得真正的并发加速
- 异步编程（asyncio）不解决 CPU 密集问题：它仍是单线程，只优化 I/O 等待，CPU 密集任务会阻塞整个事件循环
