KeyError在多线程下常因“检查后使用”竞态触发：if key in d: return d[key]中，in判断后、d[key]执行前，另一线程可能已删除该键；根本原因是dict非线程安全，GIL不保证复合操作原子性，需用threading.Lock统一保护所有读写路径。
为什么dict在多线程下会抛出KeyError？
不是因为键真不存在，而是因为in判断和__getitem__调用之间被其他线程修改了字典——典型“检查后使用”（check-then-act）竞态。比如if key in d: return d[key]，中间可能有另一线程del d[key]或d.clear()。
常见触发场景：多个线程共用一个dict做缓存、计数器、状态映射；没加锁就直接读写。
-
dict本身不是线程安全的，CPython 的 GIL 只保原子操作（如list.append），不保复合操作 -
KeyError常出现在d[key]时，但根源往往在前一步的条件判断或迭代中 - 用
try/except KeyError掩盖问题只是兜底，不能消除竞态
用threading.Lock保护共享dict最直接
对所有读写操作统一加锁，是最易理解、副作用最小的修复方式。注意锁粒度：整个dict一把锁，别为每个键建锁（开销大且难维护）。
import threading
<p>cache = {}
cache_lock = threading.Lock()</p><p>def get_value(key):
with cache_lock:
return cache[key] # 安全：不会被中途删掉</p><p>def set_value(key, value):
with cache_lock:
cache[key] = value
- 锁必须覆盖所有访问路径：包括
in、.get()、.pop()、del、.keys()等 - 避免在锁内做耗时操作（如网络请求、文件读写），否则拖慢所有线程
- 不要嵌套同一线程多次获取同一把锁（会死锁），用
threading.RLock替代
collections.defaultdict和.setdefault()能缓解但不解决竞态
它们只保证单次操作原子性，无法防止“先查再设”类逻辑。例如d.setdefault(key, init())中init()仍可能被多次调用——因为setdefault内部是“查无则设”，但init()执行不在原子范围内。
立即学习“Python免费学习笔记（深入）”；
-
d.setdefault(key, [])安全：赋值本身原子，但若后续追加元素（d[key].append(x)），仍需额外同步 -
defaultdict(list)避免KeyError，但d[key].append(x)不是原子操作，多线程下可能丢数据 - 真正安全的写法：
with lock: d[key].append(x)或改用queue.Queue、concurrent.futures等更高层抽象
用concurrent.futures.ThreadPoolExecutor替代手写线程更可靠
很多所谓“并发字典操作”其实本质是任务分发+结果聚合，没必要自己管理dict和锁。交给ThreadPoolExecutor + functools.lru_cache或线程局部存储更干净。
from concurrent.futures import ThreadPoolExecutor from functools import lru_cache <h1>缓存计算结果，自动线程安全（因装饰器内部用锁）</h1><p>@lru_cache(maxsize=128) def expensive_func(x): return x ** 2</p><p>with ThreadPoolExecutor() as executor: results = list(executor.map(expensive_func, [1, 2, 3]))
-
lru_cache自带线程锁，适合只读缓存；写入场景仍需自己同步 - 若每个线程只需独享数据，用
threading.local()比共享dict更简单、无竞争 - 高并发写多场景，考虑
shelve、sqlite3或 Redis，而非内存dict
真正麻烦的从来不是怎么加锁，而是判断哪些变量确实需要跨线程共享——多数时候，把数据拆到线程本地，比修竞态更省事。
