RLock 比 Lock 更适合字典操作，因为它允许同一线程多次 acquire 而不死锁，适配 setdefault()、update() 等内部嵌套调用；但它不解决数据竞争，仅防自锁死锁。
threading.RLock能解决 Python 字典的线程安全问题，但仅限于「你明确控制所有访问路径」的前提下；它不是万能锁，更不能掩盖设计缺陷。
为什么 RLock 比 Lock 更适合字典操作？
字典的某些操作（如 dict.setdefault()、dict.update()）内部可能递归调用其他字典方法（比如先 get() 再 __setitem__()）。普通 Lock 在同一线程内重复 acquire 会死锁，而 RLock 允许同一线程多次获取，只要释放次数匹配即可。
但这不等于“更安全”，只是“更容错”——它防止了因误写导致的自锁死锁，而非数据竞争本身。
-
RLock的重入特性对嵌套调用友好，比如你在safe_update()里又调用了safe_set() - 它仍只保护临界区入口，不保证
update()传入的other_dict是不可变或线程安全的 - 若多个线程同时往同一个 key 写不同值，
RLock只能串行化写入顺序，无法自动合并或冲突检测
必须加锁的典型字典操作有哪些？
以下操作在多线程下**一定不安全**，不加锁就直接用，结果不可预测：
-
shared_dict[key] = value（STORE_SUBSCR，含哈希、查找、可能扩容） -
shared_dict.update(other_dict)（批量写，非原子） -
shared_dict.pop(key, default)（读+删，两步） -
shared_dict.setdefault(key, default)（读+条件写，非原子）
注意：shared_dict.get(key) 或 key in shared_dict 单独使用通常不会崩溃，但若和其他线程的写操作并发，可能读到中间态（比如扩容中桶数组未完全复制完），官方文档仍将其列为「not thread-safe for mutation」的配套读操作，不推荐裸用。
加 RLock 时最容易踩的三个坑
很多人以为加上 with rlock: 就万事大吉，实际掉进这些坑才真正出问题：
- 锁粒度太大：整个函数体包在
with rlock:里，导致本可并行的读操作也被阻塞，吞吐骤降 - 忘记锁覆盖所有路径：比如
safe_get_or_create()里有if key not in d:+d[key] = ...，但if判断没进锁，就是经典 TOCTOU（time-of-check to time-of-use）漏洞 - 值对象本身被共享：锁只保护字典结构，不保护
shared_dict['config']指向的那个dict对象。如果多个线程都修改shared_dict['config']['timeout']，照样数据竞争
比 RLock 更值得优先考虑的替代方案
加锁是补救措施，不是设计起点。多数真实场景下，应优先绕过共享字典：
- 用
threading.local()：每个线程一份独立副本，零竞争，零锁开销。适合存上下文、缓存、连接池等线程私有状态 - 用
queue.Queue做生产者-消费者：把「写字典」变成「发消息」，由单个消费者线程串行处理，天然线程安全 - 改用不可变数据流：用
concurrent.futures.ThreadPoolExecutor分发任务，返回各自结果列表，主线程用dict()或functools.reduce(lambda a, b: {**a, **b}, results)合并——合并动作在单线程完成，无竞争
最后提醒一句：GIL 不是你的安全网。dict 的任何 mutation 都是多字节码操作，GIL 只保单条指令不中断，不保语义原子性。别信“Python 有 GIL 所以 dict 多线程读写没事”这种过时机说法——2026 年的 CPython 文档依然清清楚楚写着 “dict is not thread-safe for mutation”。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
