在多进程中不使用 Manager 的 dict 是否真的共享内存

不共享。普通Python dict在多进程中各自独立，fork仅触发写时复制，修改时才分配新内存页；Windows用spawn更

无自动共享。真正共享需用shared_memory、Array/Value、Manager或外部存储。

不使用 Manager 的 dict 在多进程中是否共享内存

不共享。普通 Python dict 在多进程间完全独立，每个子进程拿到的只是父进程创建时的一份拷贝，修改彼此互不影响。

为什么 fork 后看似“能读”但改不了

在 Unix/Linux 上用 fork 启动子进程时，会触发写时复制（Copy-on-Write），初始内存页是共享只读的——所以子进程能读到父进程 dict 的原始内容，但一旦任一进程尝试写入（比如 d['x'] = 1），内核就会为该进程单独复制一份内存页，后续操作只影响自己副本。

• fork 不等于共享内存，只是延迟复制
• Windows 没有 fork，multiprocessing 默认用 spawn，连初始拷贝都要显式传递，更不可能“自动共享”
• 即使你用 global dict，每个进程都有独立的全局命名空间

真正共享内存的可行方式有哪些

想让多个进程读写同一份数据，必须走明确的共享机制：

• 用 multiprocessing.shared_memory（Python 3.8+）：手动分配一块共享内存区域，配合 numpy.ndarray 或 struct 解析，适合结构化、定长数据
• 用 multiprocessing.Array / multiprocessing.Value：支持基础类型（int, float, c_char 等），线程安全但接口简陋，不适合嵌套结构
• 用 multiprocessing.Manager().dict()：底层通过代理对象 + 子进程通信实现，能用但性能差、有延迟、不支持所有 dict 操作（比如不能直接对嵌套值赋值：mgr_dict['a']['b'] = 1 会报错）
• 用外部存储（Redis、SQLite 文件、内存映射文件）：绕过 Python 进程模型限制，更灵活也更可控

一个典型误用示例和对比

下面这段代码常被误解为“共享”：

from multiprocessing import Process
d = {'counter': 0}
def worker():
d['counter'] += 1
print('in worker:', d)
if name == 'main':
p = Process(target=worker)
p.start()
p.join()
print('in main:', d)  # 输出仍是 {'counter': 0}

而换成 Manager 后才真正同步：

from multiprocessing import Process, Manager
if name == 'main':
with Manager() as manager:
d = manager.dict({'counter': 0})
p = Process(target=lambda: d.update({'counter': d['counter'] + 1}))
p.start()
p.join()
print(d)  # {'counter': 1}

注意：manager.dict() 不是内存共享，是跨进程 RPC 调用，每次访问都走序列化/反序列化，高并发下容易成瓶颈。

真正需要低延迟共享时，别碰 Manager，优先考虑 shared_memory + 自定义协议，或换用更合适的 IPC 方式。