不共享。普通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 进程模型限制，更灵活也更可控
一个典型误用示例和对比
下面这段代码常被误解为“共享”：
Linux Security Scanner
下载
Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...
from multiprocessing import Process
<p>d = {'counter': 0}</p><p>def worker():
d['counter'] += 1
print('in worker:', d)</p><p>if <strong>name</strong> == '<strong>main</strong>':
p = Process(target=worker)
p.start()
p.join()
print('in main:', d) # 输出仍是 {'counter': 0}
而换成 Manager 后才真正同步：
from multiprocessing import Process, Manager
<p>if <strong>name</strong> == '<strong>main</strong>':
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 方式。
