multiprocessing.Pool 比 threading.Thread 快得多是因为 GIL 使多线程在 CPU 密集型任务中近乎串行，而多进程绕过 GIL 并行执行；但需注意函数可 pickle、合理设置 max_workers 及子进程独立初始化。
为什么 multiprocessing.Pool 比 threading.Thread 快得多
因为 Python 的 GIL（全局解释器锁）会让 threading.Thread 在 CPU 密集型任务中几乎串行执行——所有线程轮流抢同一个锁，实际吞吐不增反可能因上下文切换变慢。而 multiprocessing.Pool 启的是独立进程，每个进程有自己完整的 Python 解释器和内存空间，天然绕过 GIL。
常见错误现象：threading.Thread 跑 4 个各耗时 1 秒的纯计算任务，总耗时仍接近 4 秒；换成 ProcessPoolExecutor 或 Pool.map 后可压到约 1.1 秒（含进程启动开销）。
- 别指望多线程能加速
numpy.dot、scipy.optimize、循环数值计算这类任务 - 若任务本身已调用底层 C 库（如 NumPy 的大部分操作），且该库已释放 GIL，则多线程可能有效——但这属于例外，不是默认行为
- 验证方式很简单：跑一个纯 Python 循环（比如斐波那契递归或大数组逐元素平方），对比线程/进程耗时
传给 pool.map 的函数必须可 pickle
multiprocessing 进程间通信依赖 pickle 序列化，所以传入 pool.map 的函数和参数必须能被序列化。否则会报 AttributeError: Can't pickle local object 或类似错误。
- 不能是
lambda函数 - 不能是嵌套函数（定义在另一个函数内部）
- 不能是类实例方法（
self.method），但可以是模块级函数或@staticmethod - 不能带闭包（比如捕获了外层函数变量的内层函数）
- 参数里不能含文件句柄、数据库连接、不可序列化的对象（如
threading.Lock）
修复方法：把计算逻辑抽成顶层函数，参数只传基本类型或 numpy.ndarray（它支持 pickle）、list、dict 等标准可序列化结构。
立即学习“Python免费学习笔记（深入）”；
pool.map 和 pool.imap_unordered 的关键区别
两者都用于批量分发任务，但行为差异直接影响结果收集逻辑和内存占用：
仅使用 Python 将 Claw Code 虚拟化框架与 OpenClaw 集成，提供 184 种工具和 200 多条命令，用于安全分析和代码质量...
-
pool.map(func, iterable)：阻塞等待全部完成，返回完整结果列表；适合结果量小、需严格顺序处理的场景 -
pool.imap_unordered(func, iterable)：返回迭代器，结果按完成先后返回（不保序），内存友好；适合流式处理或想边算边用结果
示例：处理 1000 个大数组计算，若用 map，得等全部结束才拿到 1000 个结果，内存峰值高；用 imap_unordered 可以一边 yield 一边写磁盘或发网络请求，避免内存爆掉。
别用 pool.apply_async 手动管理 callback + .get()——容易漏 .get() 导致子进程卡住，或忘记 pool.close()/pool.join()。
max_workers 设置不当反而拖慢整体性能
Pool 默认 max_workers 是 os.cpu_count()，但这只是理论最大值，不是最优值。
- 若任务本身已占满内存（比如每个进程加载一个 500MB 模型权重），开满核会触发频繁 swap，整体变慢
- 若任务涉及大量 I/O（如读写本地文件、调用外部命令），过多进程反而造成磁盘争抢
- 小任务 + 高频调用（比如每次只算几个数）时，进程创建/数据序列化开销可能吃掉并行收益，此时单进程更快
建议起步值设为 min(4, os.cpu_count()) 或 os.cpu_count() // 2，再根据实际 top 或任务管理器里的 CPU 使用率、内存增长曲线调整。尤其注意子进程启动后是否立刻进入 high CPU 状态——如果不是，大概率是 I/O 或序列化瓶颈，不是计算瓶颈。
真正容易被忽略的是：子进程启动时是“干净”状态，父进程里已导入的模块（如 numpy）、已加载的数据（如大 array）、打开的文件句柄，都不会自动继承。每个子进程要重新 import、重新加载、重新打开——这点在设计初始化逻辑时必须考虑。
