Python multiprocessing能否在反序列化前访问/保存序列化结果？

别打_result_handler的主意。这个方法是multiprocessing模块的内部私有实现，从Python 3.7到3.12的各个版本里，Pool的结果处理逻辑、队列存储结构都有过调整，直接hack私有API写出来的代码换个Python小版本就可能出兼容问题，还容易触发死锁、文件句柄泄漏这类难排查的故障。

你要省掉重复序列化/反序列化的开销，有更稳定、维护成本更低的实现方案。

方案1：在工作进程内完成序列化，零额外开销 #

这是性能最好、改动最小的方案，完全绕开主进程反序列化再重新序列化的冗余流程：

• 改造runSimulation函数，仿真逻辑跑完拿到大字典结果后，直接在当前工作进程里做pickle序列化，把序列化后的bytes对象作为返回值回传。
• 跨进程传输bytes类型时，multiprocessing内部的序列化逻辑几乎是零拷贝，不会产生额外的序列化开销。主进程拿到返回值后直接写入文件即可，全程不需要做反序列化操作。
• 如果迭代次数特别多、总数据量远大于内存容量，甚至可以直接在工作进程里把序列化结果写入独立分片文件，主进程只需要收集分片路径最后做合并，连大体积结果跨进程传输的开销都能省掉。

参考实现代码：

import os
import pickle
import multiprocessing
from pathlib import Path

def runSimulation(sim_arg):
    # 原有仿真计算逻辑
    raw_result = run_your_simulation_code(sim_arg)
    
    # 工作进程内直接完成序列化，用最高效的pickle协议
    serialized_res = pickle.dumps(raw_result, protocol=pickle.HIGHEST_PROTOCOL)
    
    # 数据量极大时直接落分片，不用跨进程传大对象
    # shard_dir = Path("./sim_result_shards")
    # shard_dir.mkdir(exist_ok=True)
    # shard_path = shard_dir / f"res_{os.getpid()}_{sim_arg}.pkl"
    # shard_path.write_bytes(serialized_res)
    # return str(shard_path)
    
    return serialized_res

if __name__ == "__main__":
    pool = multiprocessing.Pool()
    # 拿到的直接是可写入文件的序列化字节
    result_bytes_list = pool.map(runSimulation, your_sim_args_list)
    
    # 直接写入最终结果文件，不需要反序列化
    with open("all_simulation_results.pkl", "wb") as f:
        for res_bytes in result_bytes_list:
            f.write(res_bytes)

方案2：自定义队列实现结果流处理 #

如果不想改动原有runSimulation的返回逻辑，可以绕过Pool默认的map结果处理链路，自己实现任务分发和结果收集：

• 自行初始化任务队列、结果队列，启动工作进程从任务队列取参数执行仿真
• 工作进程跑完任务后，直接把序列化后的结果塞进结果队列
• 主进程启动单独的收集线程，持续从结果队列读取字节数据直接写入文件，全程不做反序列化操作
  这个方案灵活度最高，完全不依赖multiprocessing.Pool的内部实现，还可以边跑边写文件，不需要等所有任务跑完再统一落盘，内存占用更低。

• 不同Python版本中，outque里存储的数据结构不一致：多数版本里队列存的不是纯序列化结果，而是带任务ID、任务状态标记的元组，_result_handler除了反序列化结果，还要维护任务计数、异常处理逻辑，你强行截取队列里的内容会破坏Pool的状态机，很容易导致pool.map()永久阻塞。
• Windows平台使用spawn进程启动模式时，内部队列绑定了额外的句柄生命周期逻辑，跳过_result_handler直接读队列数据很容易造成文件描述符泄漏，跑的任务多了会直接把系统句柄占满。

内容的提问来源于stack exchange，提问作者VRbandname