多进程全局变量使用全攻略

Python多进程间全局变量默认不共享，这是由各进程独立内存空间的设计决定的——无论fork还是spawn方式启动子进程，全局变量都只是副本，修改互不影响；若需跨进程协调数据（如计数器、配置标志或缓存状态），必须借助multiprocessing提供的专用机制：Manager适合结构简单、读写不频繁的场景，提供dict/list等代理对象；Value和Array则基于共享内存，性能更高，适用于高频访问的单值或数组；但需注意类型码规范、赋值语法（如val.value += 1）、Windows兼容性及IPC带来的性能损耗，同时警惕第三方库全局状态、日志写入冲突等隐性陷阱。

多进程里改全局变量根本不会同步

Python 的 multiprocessing 每个子进程都拥有独立内存空间，父进程的全局变量在 fork 或 spawn 时被复制一份，后续修改互不影响。这不是 bug，是设计使然——别指望靠 global 关键字让多个进程“看到同一个变量”。

• 常见错误现象：counter = 0 在主进程定义，子进程中执行 counter += 1，最后打印还是 0
• 使用场景：计数器、缓存状态、配置标志等需要跨进程协调的数据
• 根本原因：Linux 下 fork 复制地址空间，Windows/macOS 下 spawn 重新导入模块，都不共享运行时内存

用 Manager() 共享基础数据类型最稳妥

Manager() 启动一个服务进程管理共享对象，通过代理（proxy）访问，支持 list、dict、Value、Array 等，适合低频读写、结构简单的情况。

• 实操建议：优先用 manager.dict() 或 manager.list()，避免直接传裸 dict/list
• 参数差异：manager.Value('i', 0) 中 'i' 是 ctypes 类型码，不是 Python 类型；manager.dict() 返回的是代理对象，不能直接用 .update() 批量赋值（会报 AttributeError），得逐项赋值
• 性能影响：每次访问都走 IPC，比本地变量慢 10–100 倍，别在 tight loop 里反复读写

from multiprocessing import Process, Manager
<p>def worker(shared_dict, idx):
shared<em>dict[f'proc</em>{idx}'] = idx * 2</p><p>if <strong>name</strong> == '<strong>main</strong>':
with Manager() as manager:
d = manager.dict()
ps = [Process(target=worker, args=(d, i)) for i in range(3)]
for p in ps:
p.start()
for p in ps:
p.join()
print(dict(d))  # {'proc_0': 0, 'proc_1': 2, 'proc_2': 4}</p>

Value 和 Array 适合高性能单值/数组场景

如果只共享一个整数、浮点数或固定长度数组，且读写频繁，Value 和 Array 比 Manager 快得多——它们基于共享内存（mmap），不经过服务进程中转。

• 常见错误现象：用 Value('i', 0) 后直接 val += 1，结果没变；必须用 val.value += 1
• 使用场景：计数器、状态标志、图像帧缓冲、数值计算中间结果
• 兼容性注意：Windows 下 spawn 方式需把 Value/Array 创建放在 if __name__ == '__main__': 内，否则子进程拿不到句柄
• 类型码别写错：'d' 是 double，'f' 是 float，'i' 是 signed int，写成 'int' 会报 TypeError

别碰 threading.local 或闭包变量来“模拟”共享

有人试过在进程启动前用闭包捕获变量，或误用 threading.local，结果发现完全无效——threading.local 只在单线程内有效，多进程下每个进程都有自己的 local 实例；闭包变量只是普通对象，在子进程中仍是副本。

• 典型错误代码：local = threading.local(); local.x = 1 → 子进程里 local.x 是未定义的
• 真正容易被忽略的点：连 logging 的 handler 都可能因进程隔离失效，比如用 FileHandler 时多个进程同时写一个文件会导致内容错乱，得用 QueueHandler + 主进程消费
• 复杂点在于：有些第三方库内部用了全局状态（如某些 ORM 连接池、requests 的 session 缓存），fork 后可能出连接泄漏或认证失效，得在子进程中显式重置

以上就是本文的全部内容了，是否有顺利帮助你解决问题？若是能给你带来学习上的帮助，请大家多多支持golang学习网！更多关于文章的相关知识，也可关注golang学习网公众号。