Python multiprocessing 绕过 GIL 本质是启动独立进程,需用 if name == '__main__': 保护;Pool 中 apply 同步、apply_async 异步、map 自动分片;进程间通信须用 Queue/Pipe/Value+Lock;慢在子进程初始化而非 start()。
Python 的 multiprocessing 模块不是“多线程加强版”,它绕过 GIL 的本质是启动独立进程,每个进程拥有自己的 Python 解释器和内存空间——这意味着变量不共享、对象不能直接传递、初始化开销明显。
Process 启动后子进程不执行预期代码?常见于 Windows 或 macOS 上的脚本未加保护,导致子进程重复导入主模块并递归启动新进程(表现为 CPU 占满、程序卡死或报 AssertionError: can only join a started process)。
if __name__ == '__main__': 保护块内__name__ 判断,建议改用终端执行spawn 启动方式(Windows/macOS 默认)时,模块必须可被子进程 import,避免在 if __name__ == ... 外写有副作用的顶层代码Pool 的 apply、apply_async 和 map 怎么选?三者底层都走同一套 worker 进程池调度,但调用语义和阻塞行为差异极大,误用会导致并发失效或意外同步等待。
apply(func, args):同步阻塞,等结果返回才继续,等价于单次 func(*args),无并发意义,仅用于调试apply_async(func, args):异步提交,立即返回 AsyncResult 对象,需显式调用 .get() 获取结果;若批量提交后统一 .get(),才能真正并行map(func, iterable):对可迭代对象自动分片并行执行,结果顺序与输入一致;但 iterable 会被一次性转为 list 加载进内存,大数据量时慎用from multiprocessing import Pooldef square(x): return x * x
if name == 'main': with Pool(4) as p:
✅ 正确:异步提交 + 统一取结果
results = [p.apply_async(square, (i,)) for i in range(10)] print([r.get() for r in results]) # [0, 1, 4, ..., 81] # ⚠️ 错误:每次 apply_async 后立刻 get → 退化为串行 # p.apply_async(square, (i,)).get() # 不要这样写进程间如何安全传递数据?别碰全局变量
子进程无法修改父进程的变量,
所谓“共享”只有三种可控路径:队列、管道、共享内存(
Value/Array),且每种都有适用边界。
Queue 是最常用、最安全的选择,线程/进程安全,支持任意可序列化对象,但有额外 pickle 开销Pipe() 性能更高(无序列化强制要求),但只支持两端通信,且需手动管理收发方向(a.send()/b.recv())Value 和 Array 仅支持基础类型(i, d, c 等 ctypes 类型),不能传 list/dict/自定义类;修改需加锁(Lock),否则值可能错乱所有跨进程对象(包括 Queue、Lock、Value)必须在主进程中创建,再作为参数传入子进程函数 —— 在子进程中新建等于无效。
start() 很快,但实际任务延迟很高?进程启动本身不慢,慢的是初始化:加载 Python 解释器、导入全部依赖模块、重建 sys.path、执行 __init__.py 中的代码。尤其当项目依赖 heavy 包(如 numpy、pandas、torch)时,每个子进程都要重复一遍。
initializer 和 initargs 预加载资源(如数据库连接池、模型权重),而非每次任务都重做concurrent.futures.ProcessPoolExecutor,其内部对初始化做了更稳定的封装真正的难点不在语法,而在于理解“每个进程是全新 Python 实例”这个前提——所有你以为的“自然共享”,其实都需要显式声明、显式传输、显式同步。