多线程中安全使用dict的方法

Python 的字典（dict）在多线程环境下“读安全但写危险”：虽然 GIL 保障了单个字节码的原子性，使其支持并发读取（如 `get()`、`in`、`keys()`），但任何写操作（包括 `d[k] = v`、`pop()`、`update()`）都可能触发哈希表重散列，导致内存不一致甚至崩溃——这不是小概率事件，而是确定性的安全隐患；因此必须对写操作加锁，推荐使用 `threading.RLock` 避免嵌套调用死锁，或更彻底地转向线程安全替代方案，如 `threading.local`（每线程独立副本）、`queue.Queue`（内置锁）、不可变数据流（如 `ThreadPoolExecutor` 分发+主进程聚合），从根本上规避共享可变状态的风险——别被 GIL 的表象迷惑，官方明确将 dict 列为“非线程安全的可变容器”。

多线程读 dict 是安全的，但写操作必须加锁

Python 的 dict 在 CPython 中对纯读操作（如 get()、in、keys()）是线程安全的，因为 GIL 会保证字节码级原子性；但任何修改行为（__setitem__、pop()、clear()、update()）都可能触发 rehash，导致内部结构不一致甚至崩溃。这不是“大概率出错”，而是“只要并发写就可能 segfault”——CPython 3.12 之前已多次复现过。

• 只读场景（如配置缓存）可直接共享 dict，无需额外同步
• 哪怕只是 d[k] = v 和 del d[k] 交替执行，也必须加锁
• dict.copy() 或 dict(d) 创建新副本是线程安全的，但副本本身不解决原始 dict 的并发写问题

用 threading.RLock 而不是 Lock 防止死锁

如果 dict 操作逻辑嵌套调用（比如一个函数更新 dict 后又调用另一个也更新 dict 的函数），用普通 Lock 会导致同一线程重复 acquire 阻塞。这时候 RLock 允许同一线程多次 acquire，只要对应次数 release 即可。

from threading import RLock
shared_dict = {}
dict_lock = RLock()
def safe_set(key, value):
with dict_lock:
shared_dict[key] = value
def safe_update(other_dict):
with dict_lock:
shared_dict.update(other_dict)  # 这里可能递归调用 safe_set，RLock 更稳妥

考虑 concurrent.futures.ThreadPoolExecutor + 不可变数据流

更彻底的规避方式是放弃共享 dict：让每个线程处理独立数据，最后由主线程汇总。这比加锁更易验证、无锁竞争开销，且天然避免 ABA 或迭代中修改等陷阱。

• 用 executor.map() 分发任务，返回结果列表，再用 dict() 或 functools.reduce() 合并
• 若必须边跑边聚合，可用 queue.Queue（它内部已加锁）收集中间结果
• 避免在 worker 中直接操作全局 dict，哪怕加了锁，也会成为性能瓶颈

dict 不是线程安全容器，别被 GIL 欺骗

GIL 只保护单个字节码指令不被中断，并不保证多字节码操作（如 d[k] = v 实际是 STORE_SUBSCR，涉及哈希计算、桶查找、可能的扩容）的原子性。官方文档明确将 dict 列为“not thread-safe for mutation”。真正安全的并发字典替代方案只有：threading.local()（每线程独立）、queue.Queue（带锁队列）、或第三方库如 pyrsistent.pmap（持久化不可变映射）。

最容易被忽略的是：即使你只用 setdefault() 或 get(key, default)，只要 default 是可变对象且被多个线程共享引用，仍可能引发数据竞争——锁保护的是 dict 结构，不是其中的值。

今天带大家了解了的相关知识，希望对你有所帮助；关于文章的技术知识我们会一点点深入介绍，欢迎大家关注golang学习网公众号，一起学习编程~