processpoolexecutor 适合 cpu 密集型任务，如数值计算、图像处理、加密解密；单任务耗时需超100ms，且不频繁通信或共享状态。
ProcessPoolExecutor 适合什么场景？
它只在 CPU 密集型任务里真正有用，比如数值计算、图像处理、加密解密。如果你的代码大量调用 math.sqrt、numpy.dot 或自己写的纯 Python 循环，用 ProcessPoolExecutor 才可能提速。I/O 密集型（如 HTTP 请求、文件读写）反而更慢——进程启动开销大，还容易触发系统资源限制。
- 真正加速的前提是：单个子任务耗时 > 100ms，且不共享大量状态
- 如果任务间要频繁通信或同步，别硬套
ProcessPoolExecutor，改用multiprocessing.Manager或直接上concurrent.futures.ThreadPoolExecutor（对 I/O 更友好） - Windows 下注意：必须把主模块入口包在
if <strong>name</strong> == "<strong>main</strong>":里，否则会反复 fork 子进程导致卡死
怎么传参给 map() 或 submit()？
ProcessPoolExecutor.map() 只支持单参数迭代，多参数得靠包装：
def calc(x, y, z):
return x ** 2 + y * z
<h1>❌ 错误：map 不接受 unpacked tuple</h1><h1>executor.map(calc, [(1,2,3), (4,5,6)])</h1><h1>✅ 正确：用 lambda 或 functools.partial 包一层</h1><p>executor.map(lambda args: calc(*args), [(1,2,3), (4,5,6)])</p>
submit() 更灵活，但要注意返回的是 Future 对象，不能直接取结果：
- 调用
future.result()会阻塞，批量提交后建议统一用as_completed()收集 - 参数如果是大型对象（如 pandas DataFrame、大 list），序列化开销明显，尽量提前切片或转成 numpy array 再传
为什么有时比单进程还慢？
常见原因有三个：
- 任务太轻量：比如每次只算一个
int * int，进程创建/销毁时间远超计算本身 - 数据太大：每个子进程都要 pickle/unpickle 参数，尤其含函数闭包或类实例时，慢得离谱
-
max_workers设太高：超过 CPU 核心数（os.cpu_count()）后，上下文切换反拖累性能；默认值通常是合理的，别盲目设成 100
另外注意：子进程无法访问主进程的全局变量或已导入模块状态（比如没显式 import 的 numpy），报 NameError 或 ModuleNotFoundError 是常事——所有依赖必须在子进程函数内部显式 import。
如何安全地共享中间状态？
ProcessPoolExecutor 天然不共享内存。想累计计数、收集日志或缓存中间结果，别用全局变量：
- 累加数值：让每个子任务返回局部结果，主进程用
sum()或itertools.chain合并 - 写日志：子进程用
logging.getLogger().handlers = []清空 handler，再单独配置文件输出，避免多进程抢写同一文件 - 缓存：如果逻辑允许，把缓存做成只读的
dict或numpy.memmap，通过参数传进去；写缓存一律交给主进程做
最麻烦的是需要实时更新的共享结构（比如带锁的 dict）。这时候该换方案了：用 multiprocessing.Queue 或 multiprocessing.Array，而不是硬撑在 ProcessPoolExecutor 框架里。
Python 的多进程不是银弹，尤其当你发现要绕着 pickle、GIL、进程隔离反复打补丁时，往往说明任务本身就不适合这个模型。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
