17370845950

Manager通过启动独立管理进程托管共享对象，其他进程用代理对象发RPC请求操作，每次访问均需IPC，开销大；普通dict/list因进程内存隔离无法直接共享；嵌套结构需显式用manager.dict()创建；操作非原子且性能差，高并发下管理进程成瓶颈。

Manager 是怎么让 dict/list 跨进程共享的

它不直接共享内存，而是启动一个独立的管理进程（SyncManager 子进程），所有共享对象都由这个进程托管。其他进程通过代理（proxy）对象间接读写——实际是发 RPC 请求给管理进程，由它完成操作再返回结果。

这意味着：dict 和 list 看起来像本地对象，但每次访问（哪怕只是 len(d) 或 d.keys()）都涉及进程间通信（IPC），开销远大于普通对象。

为什么不能直接传普通 dict/list 给子进程

因为 multiprocessing 默认用 fork（Unix）或 spawn（Windows/macOS）方式启动子进程，父子进程内存空间完全隔离。你传一个普通 dict，子进程拿到的是副本，修改不会反映回父进程，反之亦然。

常见错误现象：

• 子进程中修改 shared_dict['x'] = 1，父进程里读不到变化
• 用 manager.dict() 初始化后，误当成普通 dict 调用 .update() 或解包（{**d}），结果报 TypeError: unhashable type: 'DictProxy'

Manager.dict() 和 Manager.list() 的行为边界

它们只保证顶层对象可共享，嵌套结构默认不自动代理。比如：

d = manager.dict()
d['nested'] = {'a': 1}  # ❌ 这个内层 dict 不受管理，修改不会同步
d['nested'] = manager.dict(a=1)  # ✅ 才能跨进程更新 a

常用操作兼容性注意点：

• dict 支持：__getitem__, __setitem__, keys(), values(), items()，但不支持 popitem()、setdefault()（会抛 AttributeError）
• list 支持：append(), extend(), __getitem__, __setitem__，但不支持切片赋值（l[1:3] = [4,5] 报错）
• 所有操作都不是原子的——d['x'] += 1 是读+算+写三步，多进程下可能丢更新，需配合 Lock

性能差在哪？什么时候该换方案

每次访问都要走 IPC，实测在千次级操作时延迟已是毫秒级；若频繁读写（如循环中反复 d[k] += 1），性能可能比单进程还慢。

替代建议：

• 高频小数据：改用 multiprocessing.Queue 或 multiprocessing.Pipe 主动推送变更
• 只读大字典：用 multiprocessing.Value + ctypes 或序列化后共享内存（shared_memory 模块，Python 3.8+）
• 需要原子计数器：直接用 multiprocessing.Value('i', 0) 配合 Lock，比 Manager.dict() 快一个数量级

最易被忽略的一点：Manager 进程本身是单点，如果大量子进程同时高并发调用，它会成为瓶颈，且一旦崩溃，所有 proxy 对象失效——别把它当数据库用。