multiprocessing.Pool是最直接有效的选择，但需绕开GIL、确保函数可序列化、匹配任务粒度；threading.Thread因GIL对纯计算无效；pool.map阻塞返回完整列表，pool.imap_unordered返回无序迭代器；函数须为模块级且参数可序列化；避免滥用apply_async。
multiprocessing.Pool 是最直接有效的选择，但必须绕开 GIL、确保函数可序列化、并匹配任务粒度——否则反而更慢。
为什么 threading.Thread 对纯计算没用
Python 的 GIL 会强制所有线程轮流执行 Python 字节码。哪怕你启了 8 个 threading.Thread 去算斐波那契或遍历大数组，实际仍是串行跑，总耗时≈单线程 × 任务数。
而 multiprocessing.Pool 启的是独立进程，每个有自己解释器和内存，天然绕过 GIL，真并行。
- 验证方法：写个纯 Python 循环（比如
sum(i*i for i in range(10**7))），分别用线程和进程跑 4 次，看耗时对比 - 注意：NumPy/scipy 等底层 C 库若已释放 GIL，多线程可能有效——但这属于例外，不是默认行为
pool.map 和 pool.imap_unordered 怎么选
两者都分发批量任务，但返回方式和内存行为差异极大：
-
pool.map(func, iterable)：阻塞等待全部完成，返回完整list；适合结果少、需严格保序、后续要整体处理的场景 -
pool.imap_unordered(func, iterable)：返回迭代器，结果按完成先后 yield，不保序；适合大数据流、边算边存/发、避免内存爆掉 - 例如处理 500 个 100MB 数组：用
map会等全部结束才返回，峰值内存可能超 50GB；用imap_unordered可逐个写磁盘，内存恒定
传给 pool.map 的函数必须能被 pickle
进程间靠序列化传递函数和参数，以下写法全会报 AttributeError: Can't pickle local object：
立即学习“Python免费学习笔记（深入）”；
- lambda 函数：
pool.map(lambda x: x**2, data) - 嵌套函数：
def outer(): def inner(x): return x+1; return pool.map(inner, data) - 类实例方法：
obj.compute()（self不可序列化） - 带闭包的函数（捕获了外层变量）
修复办法只有一条：把计算逻辑抽成模块级函数，参数只传基本类型、list、dict、numpy.ndarray 等可序列化对象。
别用 pool.apply_async + .get() 手动管理
看似灵活，实则极易出错：
- 漏调
.get()：子进程结果卡在管道里，主进程 hang 住 - 忘调
pool.close()和pool.join()：子进程变成僵尸进程，资源泄漏 - 大量小任务高频调用时，
apply_async的调度开销可能压倒并行收益
除非你需要为每个任务设不同超时或回调，否则优先用 map 或 imap_unordered ——它们自动处理生命周期。
