根本原因是每次put()/get()强制完整pickle：500MB DataFrame触发数GB内存拷贝和CPU密集编码，95%耗时在pickle.dumps()/loads()；IPC还引入双次内存复制与上下文切换；应改用shared_memory零拷贝或loky后端缓存。
multiprocessing.Queue序列化开销是根本原因
不是Queue本身慢，而是每次put()或get()都强制走完整pickle流程：对象被pickle.dumps()序列化 → 写入内核管道 → 子进程pickle.loads()反序列化。一个500MB的pandas.DataFrame会触发数GB内存拷贝和CPU密集型编码，耗时集中在序列化阶段，而非队列逻辑。
IPC底层机制放大延迟
multiprocessing.Queue基于操作系统管道（pipe）或共享内存+信号量实现，但无论哪种，数据都要从用户空间拷贝到内核空间、再拷贝到另一端用户空间。对大对象而言，这意味至少两次全量内存复制 + 两次上下文切换。实测显示：传100MB对象，put()平均耗时2.3秒，其中95%花在pickle.dumps()上。
比Pool.map更隐蔽的陷阱
- 看起来像“异步通信”，实际仍是同步阻塞：调用
put()直到序列化完成并写入内核缓冲区才返回 - 无法复用已序列化的结果——即使同一对象反复
put()，每次都要重做dumps() - 错误地用
queue.Queue替代（非进程安全）会导致静默数据损坏，而非报错 - Windows下还叠加了spawn启动开销，子进程需重新pickle父进程整个模块状态
真正该用什么替代Queue传大对象
直接绕过序列化：
- 只读场景：用
multiprocessing.shared_memory.SharedMemory+ 元信息（shape、dtype）传递，子进程用np.ndarray(..., buffer=shm.buf)零拷贝重建视图 - 需修改且有同步需求：改用
multiprocessing.Manager().dict()或.Array()，但注意它内部仍走代理+序列化，仅适合KB级小数据 - IO密集型任务（如API请求）：别用多进程传数据，改用
asyncio+aiohttp，避免进程开销 - 已有代码难改：换
joblib.Parallel(backend="loky")，它对重复大对象自动启用内存映射缓存，省掉重复dumps()
关键点：共享内存不解决“谁来写”的问题——如果多个进程要并发写同一块shm，必须自己加multiprocessing.Semaphore或Lock，否则数据会错乱。这点常被忽略。
立即学习“Python免费学习笔记（深入）”；
