pool适合cpu密集型、无共享状态、可序列化的纯计算任务；不适合io密集型、含全局变量、lambda或嵌套函数的任务。

直接用 multiprocessing.Pool 并不能自动加速所有任务——它只对 CPU 密集型、无共享状态、可序列化的函数有效；IO 密集型或带全局变量/类实例的任务反而可能更慢甚至出错。

Pool 适合什么场景？看三个硬性条件

能用 Pool 加速的前提是：函数纯计算、不依赖外部状态、参数和返回值都能被 pickle 序列化。

• ✅ 适合：数值计算（如矩阵运算、图像滤波）、文本解析（正则匹配、分词）、加密哈希生成
• ❌ 不适合：调用未加锁的全局计数器、操作 threading.local()、传入 lambda 或嵌套函数（无法 pickle）、读写同一文件句柄
• ⚠️ 警惕：含 numpy 数组的函数通常没问题，但若函数内动态 import 模块或修改 sys.path，子进程可能找不到模块

map() vs apply_async()：选错就卡死或失控

map() 是阻塞式批量提交，等全部完成才返回；apply_async() 是非阻塞单次提交，适合异步控制流，但不手动 .get() 就拿不到结果。

Li Python Sec Check

Python 安全规范检查工具：基于 CloudBase 规范、腾讯安全指南，LLM 智能分析（默认禁用，优先本地执行）

下载

• pool.map(func, iterable)：最常用，自动切分 iterable 给各 worker，但会一次性加载全部数据到内存——大数据量时用 pool.imap() 流式处理
• pool.apply_async(func, args=(x,), kwds={'y': 1})：返回 AsyncResult 对象，必须显式调用 .get(timeout=10) 获取结果，否则主进程可能提前退出，子进程变僵尸
• 别混用：在循环里反复调 apply_async 却不收集结果，会导致 AsyncResult 对象堆积，内存泄漏

常见报错和对应解法

错误信息如 PicklingError: Can't pickle <function ...></function> 或 BrokenProcessPool，基本都源于序列化失败或资源竞争。

• 报 PicklingError：把函数移到模块顶层（别放在类方法或 if __name__ == '__main__': 块里），避免使用 lambda、functools.partial（改用普通函数+默认参数）
• 报 BrokenProcessPool：子进程崩溃（如除零、段错误），检查函数是否含未捕获异常；Windows 下必须用 if __name__ == '__main__': 包裹 Pool 创建逻辑
• 结果顺序错乱：用 pool.map() 保持输入顺序；用 apply_async 时，手动存 result = pool.apply_async(...) 再按需 result.get()，别依赖提交顺序

真正难的不是写几行 Pool 代码，而是判断任务是否真的适合并行——比如一个函数内部频繁访问 Redis 或数据库，开 8 个进程只会让连接池打满，反而拖垮整体响应时间。

Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！