Python中CPU密集任务慢的核心是CPython的GIL限制多线程并行，应使用multiprocessing实现真正并行；concurrent.futures.ProcessPoolExecutor更简洁；Cython/Numba、PyPy、Dask/Joblib等为进阶选项，需权衡场景。
Python中CPU密集任务跑得慢，核心问题是CPython的GIL（全局解释器锁）限制了多线程对CPU的真正并行利用。要提速，必须绕过GIL——最直接有效的方式是用多进程（multiprocessing），而非多线程。
为什么多线程对CPU密集任务基本无效
CPython中，同一时刻只有一个线程能执行Python字节码。即使你开了10个线程处理计算，它们仍被GIL串行调度，实际占用单个CPU核心，总耗时可能比单线程还长（因线程切换开销）。这和IO密集型任务完全不同——后者线程在等待磁盘或网络时会主动释放GIL，所以多线程有用。
首选方案：multiprocessing 并行化
每个进程拥有独立的Python解释器和内存空间，完全绕过GIL，实现真正的CPU并行。适合可拆分、无强状态依赖的计算任务。
- 用
multiprocessing.Pool最简单：支持map、apply_async等接口，自动管理进程生命周期 - 输入数据尽量序列化（如list、dict、numpy array），避免传入不可序列化的对象（如lambda、嵌套类实例）
- 进程数建议设为
os.cpu_count()或略少（留1–2核给系统），过多反而因上下文切换拖慢整体速度 - 示例：对10万数字求平方根，用
Pool.map比单进程快接近N倍（N为逻辑CPU数）
进阶选择：concurrent.futures.ProcessPoolExecutor
比原生 multiprocessing 更简洁、更符合现代Python风格，支持上下文管理（with）和统一的异步接口。
立即学习“Python免费学习笔记（深入）”；
- 代码结构清晰：提交任务用
submit()，批量用map()，结果通过Future.result()获取 - 异常传播友好：子进程报错会在主进程
result()调用时原样抛出，便于调试 - 适合需要灵活控制任务提交节奏、或混合使用多进程/多线程（如CPU+IO混合场景）的项目
其他可行但需谨慎的方向
不是所有情况都适合一刀切上多进程。有些场景更适合换底层或调优：
-
用Cython或Numba加速单函数：对热点计算函数加装饰器（如
@njit）或编译为C扩展，避免进程间数据拷贝开销 - 改用PyPy（慎选）：PyPy无GIL，多线程可并行，但对NumPy/C扩展兼容性差，且启动慢，适合纯Python长时计算
- 用Dask或Joblib：Joblib对科学计算友好（自动缓存、支持共享内存数组），Dask适合超大数据分片调度，但引入额外依赖和学习成本
不复杂但容易忽略：数据分发和结果聚合本身有开销。如果单个子任务太小（比如每次只算1个数），多进程反而更慢。确保每个子任务耗时在毫秒级以上，才能体现并行收益。
