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 RLockshared_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（持久化不可变映射）。
立即学习“Python免费学习笔记（深入）”；
最容易被忽略的是：即使你只用 setdefault() 或 get(key, default)，只要 default 是可变对象且被多个线程共享引用，仍可能引发数据竞争——锁保护的是 dict 结构，不是其中的值。
