为何Python多进程Manager创建的共享字典读取比磁盘还慢？

根本原因分析 #

1. Manager共享字典是跨进程代理，而非直接内存访问 #

multiprocessing.Manager()会启动一个独立的服务进程，你创建的manager.dict()并不是本地内存中的普通字典，而是一个代理对象。子进程每次读取这个字典时，都要通过IPC（进程间通信，通常是管道或套接字）向Manager服务进程发送请求，服务进程处理后再把数据序列化并返回给子进程——整个过程完全不是直接读取内存，而是跨进程的远程调用。

2. 大对象的序列化/反序列化开销远超磁盘IO #

你的字典中存储的是数百MB的sklearn模型，这类复杂Python对象的序列化（默认用pickle）需要遍历整个对象结构，把所有数据转换成字节流；反序列化则要反向重建对象。这个过程的CPU开销极大，远超过从磁盘读取相同大小二进制文件的IO耗时。

对比磁盘读取的流程：磁盘读二进制文件→反序列化为模型，仅需一次反序列化；而用Manager共享字典的流程是：Manager进程内的模型→序列化→IPC传输→子进程反序列化，多了一次序列化+IPC传输的双重开销，这是耗时翻倍的核心原因。

3. 锁机制与并发请求放大延迟 #

Manager的共享字典是线程安全的，内部用锁保证多进程访问的一致性。当多个子进程同时请求读取大对象时，锁会让请求排队等待，每个请求的处理时间（序列化+传输）本身就很长，排队会进一步放大整体耗时，最终导致总耗时远超磁盘读取。

补充优化思路（可选） #

如果需要提升效率，可以考虑以下方案：

• 子进程独立加载模型：每个子进程自己从磁盘读取并反序列化模型，避免跨进程通信开销。Unix系统下可利用fork的写时复制特性，在创建Pool前主进程先加载模型，子进程直接继承内存中的模型副本，读取无额外开销。
• 用共享内存存储：将序列化后的模型字节数据存入multiprocessing.Array或第三方共享内存库，子进程读取后自行反序列化，减少IPC的往返请求。
• 避免共享大对象：尽量把大对象的加载逻辑放在子进程内部，而非通过Manager共享。

代码示例 #

pool = multiprocessing.Pool(processes=self.process_num)
manager = multiprocessing.Manager()
models_and_configs_dict = manager.dict()

# 此处从磁盘读取内容，存入字典，键为数字，值是包含两个键的复杂字典：'models'是存放sklearn模型（可达数百MB）的列表，'configs'是存放简单文本字典的列表。

# 启动子进程读取模型并执行数据检测
for i in range(self.process_num):
    pool.apply_async(detect_model, args=(models_and_configs_dict, ))

# 子进程中读取模型的逻辑，这两行代码耗时10秒以上
models = models_and_configs[models_and_configs_id]['models']
config = models_and_configs[models_and_configs_id]['configs']

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