直接用 dict 传给子进程会导致内存翻倍，因 fork 后的写时复制被 Python 内部操作（如引用计数、哈希查找）意外触发；共享只读字典应使用 shared_memory + 序列化，配合显式清理。
直接用 dict 传给子进程，内存几乎必然翻倍——不是因为你要改它，而是 Python 解释器自己就在偷偷写它。
为什么 fork 后大字典会触发写时复制？
Linux/macOS 上 fork() 默认启用写时复制（CoW），但“只读”非常脆弱。哪怕子进程只是调用 print(big_dict) 或执行一次 len()，CPython 内部的引用计数更新、GC 标记、甚至字典哈希表探查过程，都可能落在同一内存页上，导致整页被复制。实测中，一个 200MB 的只读字典，在子进程首次访问后，RSS 立即涨到 400MB+。
常见触发点包括：
-
sys.getrefcount()、gc.collect()等调试/清理操作 - 任何对字典的遍历（
for k in d:、d.keys()、list(d)） - 哪怕只是
if 'key' in d:，底层仍需哈希查找并可能修改内部状态 - 日志输出、异常 traceback 中自动字符串化字典内容
用 multiprocessing.Manager().dict() 会更省内存吗？
不会，反而更重。它背后是独立的服务器进程 + 序列化 + 网络式通信（实际走本地 socket 或 pipe），每次读写都要 pickle/unpickle，不仅不共享物理内存，还引入额外拷贝和延迟。一个 100MB 字典通过 Manager().dict() 修改 10 次，实际内存占用可能突破 500MB，且 CPU 花在序列化上远多于计算。
立即学习“Python免费学习笔记（深入）”；
它只适合：
– 数据极小（KB 级）、写入频率极低
– 必须支持任意 Python 对象（比如嵌套类实例）
– 完全不关心性能，只要逻辑能跑通
真正零拷贝共享只读字典的方案
核心思路：让字典数据脱离 Python 堆，变成操作系统级只读内存段，子进程只能读，解释器无法写。
推荐组合：
- 用
json或msgpack将字典序列化为 bytes，写入multiprocessing.shared_memory.SharedMemory（Python 3.8+） - 子进程中用
memoryview或numpy.frombuffer()直接解析结构（如果格式规整），或用json.loads()按需反序列化键值（避免全量加载） - 若必须用 dict 接口，可封装一层只读代理，如
types.MappingProxyType——但它仅防误改，不防 CoW；必须配合共享内存前置使用才有效
示例关键片段：
from multiprocessing import shared_memory
import json
<h1>主进程：预加载并共享</h1><p>data = {"user_123": {"score": 95, "tags": ["a", "b"]}, ...}
serialized = json.dumps(data).encode("utf-8")
shm = shared_memory.SharedMemory(create=True, size=len(serialized))
shm.buf[:len(serialized)] = serialized</p><h1>子进程：只读访问，不触发 CoW</h1><p>with open(shm.name, "rb") as f: # 实际用 shm.name + attach
raw = bytes(shm.buf)
d = json.loads(raw) # 按需解析，非强制全量
最容易被忽略的清理细节
SharedMemory 对象必须显式 .close() 和 .unlink()，否则 /dev/shm/ 下的文件永久残留——尤其在频繁启停进程的开发或测试中，几天就能占满 2GB 默认空间。PyTorch 用户更要注意：torch_shm_* 文件与 SharedMemory 共用同一挂载点，混用时极易冲突。
安全做法：
- 始终在
try/finally中调用shm.close() - 仅由创建者调用
shm.unlink()，且确保所有子进程已 detach - 上线前检查
df -h /dev/shm，设置合理大小（mount -o remount,size=4G /dev/shm）
