应使用loop.run_in_executor()将multiprocessing.Pool调用提交至线程池执行，每次需新建Pool实例且函数须顶层定义；更推荐直接使用ProcessPoolExecutor，但需注意Windows下需if __name__ == "__main__":保护及参数兼容性。
asyncio 里怎么安全调用 multiprocessing.Pool
不能直接在 async def 函数里 pool.map()，会阻塞事件循环。Python 的 multiprocessing.Pool 是同步阻塞接口，而 asyncio 要求协程不主动让出 CPU —— 两者底层调度机制冲突。
正确做法是用 loop.run_in_executor() 把进程池调用扔进线程池“伪装”成异步操作（注意：这里只是调度包装，实际仍走多进程）：
import asyncio
from multiprocessing import Pool
<p>def cpu_bound_task(x):
return x ** 2</p><p>async def run_in_pool(data):
loop = asyncio.get_running_loop()
with Pool() as pool:</p><h1>注意：必须在 run_in_executor 中完成整个 pool 调用</h1><pre class='brush:python;toolbar:false;'> # 不能把 pool 实例传进协程里复用
result = await loop.run_in_executor(None, pool.map, cpu_bound_task, data)
return result</pre>-
run_in_executor的第一个参数为None表示使用默认的concurrent.futures.ThreadPoolExecutor，它能安全调用Pool.map - 每次都要新建
Pool()，不能在协程外初始化后传入 ——Pool对象不可跨进程序列化，会报PicklingError - 如果数据量大，
pool.map本身有开销，建议批量传入，别单个元素反复调用
为什么不用 ProcessPoolExecutor 替代 multiprocessing.Pool
concurrent.futures.ProcessPoolExecutor 是更自然的 async 配合选择，它本身支持 run_in_executor，且无需手动管理 Pool 生命周期。
但要注意：它和 multiprocessing.Pool 在参数行为上不完全等价：
立即学习“Python免费学习笔记（深入）”；
-
ProcessPoolExecutor(max_workers=4)启动固定数量子进程，复用；multiprocessing.Pool(4)也类似，但前者更轻量 -
ProcessPoolExecutor不支持pool.apply_async(callback=...)这类回调模式，得靠await future或as_completed - Windows 下，
ProcessPoolExecutor必须在if __name__ == '__main__':块中启动，否则子进程导入失败 —— 这点常被忽略，报错是RuntimeError: An attempt has been made to start a new process before the current process has finished its bootstrapping phase
asyncio + 多进程时如何传参和取返回值
所有传给子进程的参数必须可被 pickle 序列化，函数也必须在模块顶层定义（不能是闭包、lambda 或类方法），否则 AttributeError: Can't pickle local object。
- 避免传递实例方法：
obj.method→ 改为普通函数 + 显式传obj属性 - 复杂对象如
numpy.ndarray可以传，但要注意共享内存需额外处理（默认是拷贝） - 返回值同样受限于
pickle，比如生成器、文件句柄、线程锁都不能返回 - 如果需要返回大量数据，考虑用
mmap或临时文件路径代替直接返回，减少序列化开销
什么时候该放弃多进程、改用其他方案
不是所有“计算密集”都适合开进程 —— 进程创建/通信成本可能超过收益。
- CPU 核心数 ≤ 2 时，多进程收益极低，甚至更慢；优先考虑算法优化或 Cython 加速
- 任务粒度太小（比如每次计算几毫秒），
IPC开销会吃掉全部优势；这时用numba.jit或向量化更有效 - 如果任务间有强依赖或需频繁通信，
multiprocessing.Manager或Queue会严重拖慢，不如退回到单进程 +asyncio.to_thread（Python 3.9+）做轻量隔离 - 容器环境（如 Docker）里限制了
/dev/shm大小，multiprocessing共享内存可能失败，错误信息通常是OSError: [Errno 28] No space left on device
多进程不是银弹，尤其和 async 混用时，边界条件比想象中多得多 —— 比如子进程崩溃不会自动抛到主线程，得靠 future.exception() 主动检查。
