如何解决Python大对象在多进程传递时的序列化开销？-Python教程-PHP中文网

因为pickle需对大对象执行全量内存拷贝和cpu密集型序列化，非引用传递；python 3.8+ spawn方式更严重，必须全量pickle，导致process启动延迟、memoryerror或pool.map耗时剧增。

如何解决python大对象在多进程传递时的序列化开销？

为什么 `pickle` 在多进程传大对象时会卡住？

因为 multiprocessing 默认用 pickle 序列化所有参数和返回值，而大对象（如几百 MB 的 numpy.ndarray、pandas.DataFrame 或嵌套字典）在 pickle.dumps() 和 pickle.loads() 阶段会触发完整内存拷贝 + CPU 密集型编码，不是“传引用”，更不是共享内存。

常见现象：Process.start() 延迟数秒甚至分钟；子进程启动后立刻 MemoryError；Pool.map() 耗时 90% 都花在序列化上。

Python 3.8+ 的 spawn 启动方式比 fork 更严重——它不继承父进程内存，必须全量 pickle
__getstate__/__setstate__ 自定义无法绕过主对象的 pickle 入口，治标不治本
即使对象本身支持 __slots__ 或是 dataclass(frozen=True)，只要尺寸大，开销照旧

用 `multiprocessing.shared_memory` 手动共享 NumPy 数组

适用于：只读或明确同步写入的大型 numpy.ndarray（尤其是 float/int 类型），且各进程需访问相同切片或全量数据。

核心思路：把数组数据写进系统共享内存块（SharedMemory），再把 shape/dtype 信息单独传过去，子进程用 np.frombuffer() 重建视图——全程零拷贝、不走 pickle。

必须显式创建 SharedMemory 实例，并在所有进程结束后调用 .close() 和 .unlink()
shape/dtype/offset 等元信息仍需通过 args 传入，但体积可忽略（几十字节）
注意对齐：确保 shm.buf[n:n+size] 访问不越界，建议用 np.ndarray(shape, dtype, buffer=shm.buf) 构造

# 父进程
import numpy as np
from multiprocessing import shared_memory, Process
<p>arr = np.random.rand(10000, 1000)  # ~800MB
shm = shared_memory.SharedMemory(create=True, size=arr.nbytes)
shared_arr = np.ndarray(arr.shape, dtype=arr.dtype, buffer=shm.buf)
shared_arr[:] = arr[:]  # 复制数据到共享内存</p><h1>启动子进程，只传 shm.name、shape、dtype</h1><p>p = Process(target=worker, args=(shm.name, arr.shape, arr.dtype))
p.start()
p.join()</p><p>shm.close()
shm.unlink()  # 必须，否则残留
</p>

用 `joblib.Parallel` + `backend="loky"` 替代原生 Pool

当无法改代码结构（比如已有大量 map(func, data) 调用），又想减少 pickle 开销时，joblib 是最平滑的替代方案。

python-script-generator

快速生成专业的 Python 脚本和应用代码。一键创建完整项目结构，支持CLI、API、爬虫、Bot、Django等多种项目类型，包含完整的项目结构、配置文件、依赖管理、测试、README和文档。

下载

它底层用 loky 启动器，默认启用「智能 pickle 缓存」和「内存映射优化」，对重复出现的大对象（如模型权重、静态特征矩阵）会复用已序列化的 blob，避免重复 encode/decode。

必须加 max_nbytes=None 或设为较大值（默认 1GB），否则 joblib 会自动退化为 disk-backed mmap，反而变慢
对含不可 pickle 成员（如文件句柄、lambda）的对象仍会失败，和原生 multiprocessing 一致
不兼容 Windows 上的某些交互式环境（如 Jupyter kernel 重启后 shm 句柄失效）

from joblib import Parallel, delayed
<h1>替换原来的 pool.map(...)</h1><p>results = Parallel(n_jobs=4, backend="loky", max_nbytes=None)(
delayed(my_func)(x, large_readonly_data) for x in inputs
)
</p>

什么时候该放弃多进程，改用多线程或异步？

如果大对象主要是 I/O 绑定（如从 HDF5/Parquet 文件反复读某列）、或计算本身不重（比如每条记录只做简单变换），多进程的序列化 + 进程启动开销很可能超过收益。

此时 concurrent.futures.ThreadPoolExecutor 是更优解：线程间直接共享内存，无 pickle，且 Python GIL 对 NumPy/Cython 等释放充分。

确认你的计算函数是否调用了 NumPy/Pandas/Cython——如果是，GIL 大概率已释放，线程能真正并行
若函数里混有纯 Python 循环（如 for x in list: total += x**2），GIL 未释放，线程会串行，此时应回退到单进程 + numba.jit 或 Cython 加速
异步（asyncio）仅适合高并发 I/O 场景（如批量 HTTP 请求），对本地大数组计算无意义

真正难处理的是那种既需要跨进程隔离（防崩溃）、又要高频读写同一块 GB 级内存的场景——这时得上 torch.multiprocessing 的共享 CUDA 张量，或者自己用 mmap + 文件锁做精细控制。