如何修复Python中因并发竞争导致的KeyError冲突？

多线程下遇到的 KeyError，十有八九不是键真的不存在，而是因为那个经典的“检查后使用”竞态条件——你刚用 if key in d 判断完，还没等执行 d[key]，另一个线程就把这个键删掉了。根本原因在于 Python 的 dict 并不是线程安全的，GIL 虽然能保护单个字节码指令，但像 in 判断加 __getitem__ 这种复合操作，它管不了。要彻底解决，就得用 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
cache = {}
cache_lock = threading.Lock()

def get_value(key):
    with cache_lock:
        return cache[key]  # 安全：不会被中途删掉

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() 执行不在原子范围内。

• 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

# 缓存计算结果，自动线程安全（因装饰器内部用锁）
@lru_cache(maxsize=128)
def expensive_func(x):
    return x ** 2

with ThreadPoolExecutor() as executor:
    results = list(executor.map(expensive_func, [1, 2, 3]))

• lru_cache 自带线程锁，适合只读缓存；写入场景仍需自己同步
• 若每个线程只需独享数据，用 threading.local() 比共享 dict 更简单、无竞争
• 高并发写多场景，考虑 shelve、sqlite3 或 Redis，而非内存 dict

真正麻烦的从来不是怎么加锁，而是判断哪些变量确实需要跨线程共享——多数时候，把数据拆到线程本地，比修竞态更省事。