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__':保护块内 - 在 IDE（如 PyCharm）中运行时，需确认是否启用了 “Run with Python console” —— 这会破坏
__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 Pool
<p>def square(x):
return x * x</p><p>if <strong>name</strong> == '<strong>main</strong>':
with Pool(4) as p:</p><h1>✅ 正确：异步提交 + 统一取结果</h1><pre class='brush:python;toolbar:false;'> 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），且每种都有适用边界。
立即学习“Python免费学习笔记（深入）”；
-
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）时，每个子进程都要重复一遍。
- 避免在子进程函数中动态 import 大库；应在函数顶部一次性导入，让 spawn 机制复用已加载状态
- 用
initializer和initargs预加载资源（如数据库连接池、模型权重），而非每次任务都重做 - 考虑改用
concurrent.futures.ProcessPoolExecutor，其内部对初始化做了更稳定的封装
真正的难点不在语法，而在于理解“每个进程是全新 Python 实例”这个前提——所有你以为的“自然共享”，其实都需要显式声明、显式传输、显式同步。
