对纯计算密集型任务，用 multiprocessing.Pool 或 ProcessPoolExecutor 最简单有效；因绕开 GIL 实现真并行，而 threading.Thread 受 GIL 限制实为串行。
直接结论：对纯计算密集型任务，用 multiprocessing.Pool 或 concurrent.futures.ProcessPoolExecutor 是最简单有效的提速方式；但必须绕开 GIL，且不能传不可序列化的对象。
为什么 multiprocessing.Pool 比 threading.Thread 快得多
Python 的 GIL（全局解释器锁）会让多线程在 CPU 密集型任务中几乎无法并行——所有线程轮流抢同一个锁，实际是串行执行。而 multiprocessing 启的是独立进程，每个进程有自己独立的 Python 解释器和内存空间，天然绕过 GIL。
常见错误现象：threading.Thread 跑 4 个耗时 1 秒的计算，总耗时仍接近 4 秒；换成 ProcessPoolExecutor 后可压到约 1.1 秒（含进程启动开销）。
注意点：
立即学习“Python免费学习笔记（深入）”；
- 进程间通信靠序列化（pickle），所以传入
pool.map的函数和参数必须可 pickle（不能是 lambda、嵌套函数、类实例方法等） - 小任务 + 高频调用时，进程启动/数据序列化开销可能抵消并行收益，此时不如单进程
- 默认
max_workers是os.cpu_count()，但若任务本身已占满内存或触发频繁 swap，反而会拖慢
Pool.map 与 Pool.imap_unordered 的关键区别
两者都用于批量分发任务，但行为差异直接影响结果收集逻辑和内存占用：
-
pool.map(func, iterable)：阻塞等待全部完成，返回完整结果列表；适合结果量小、需顺序处理的场景 -
pool.imap_unordered(func, iterable)：返回迭代器，结果按完成先后返回（不保序），内存友好；适合流式处理或想边算边用结果 - 别用
pool.apply_async手动管理 callback + get —— 容易漏.get()导致子进程卡住，或忘记pool.close()/pool.join()
示例对比：
with Pool(4) as pool:
# 全部算完才返回 list，内存存 350 个结果
results = pool.map(compute_something, params)
<p>with Pool(4) as pool:</p><h1>每出一个结果就打印，不等其他</h1><pre class="brush:php;toolbar:false;">for res in pool.imap_unordered(compute_something, params):
print(res)
concurrent.futures.ProcessPoolExecutor 更推荐用于新项目
相比原生 multiprocessing.Pool，ProcessPoolExecutor 接口更现代、异常传播更直观、资源管理更鲁棒（自动 shutdown(wait=True)）。
使用场景：
- 需要捕获子进程中抛出的异常（
Pool中异常会被吞掉或报PickleError） - 想统一用
as_completed处理不同任务类型混合提交（比如部分 IO、部分 CPU 任务） - 配合超时控制：
executor.submit(func, arg).result(timeout=30)
注意兼容性陷阱：
- Windows 下必须将进程启动代码包在
if __name__ == "__main__":块内，否则反复 fork 子进程导致崩溃 - 子进程无法继承父进程的 logging 配置、全局变量、数据库连接等，需在 worker 函数内重新初始化
容易被忽略的三个性能坑
提速失败往往不是因为没用多进程，而是栽在这几个细节上：
-
func内部用了numpy或scipy等底层库？它们本身已用 OpenMP 多线程并行，再套一层进程池可能引发线程竞争，反而变慢；此时应先设export OMP_NUM_THREADS=1关闭其内部多线程 - 传入参数是大对象（如 500MB 的
numpy.ndarray）？每次都会被 pickle → copy → unpickle，开销巨大；改用multiprocessing.shared_memory或numpy.memmap共享内存 - 任务粒度太细（比如每次只算 1 行数据，但要跑 10 万次）？应先 batch 处理（如每进程处理 100 行），减少进程间调度和序列化次数
真正难的从来不是“怎么开多进程”，而是判断“该不该开”、以及“怎么让每个进程真正忙起来而不是互相等”。
