17370845950

Python dict多线程读安全但写必须加锁，因GIL不保证多字节码操作原子性；推荐用RLock防嵌套死锁，或改用threading.local、queue.Queue等真正线程安全方案。

多线程读 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 结构，不是其中的值。