pytest测多线程安全会“测不准”是因为其单线程执行机制导致测试函数返回即判定完成，后台线程可能未结束；必须用join显式同步、Event/Lock制造竞态、捕获线程异常并共享被测对象。
为什么直接用 pytest 测多线程安全会“测不准”
因为 pytest 默认是单线程执行测试函数，即使你在测试里手动启动多个 threading.Thread，它也不会自动等待所有线程结束就判定测试通过——test_* 函数一返回，pytest 就认为测试完成，后台线程可能还在跑，甚至刚执行到一半。结果就是：看似通过，实则竞态未暴露；或者偶尔失败，难以复现。
关键点在于：必须显式同步线程生命周期，否则测试不具备可重复性。
- 别依赖
time.sleep()等待，它既不可靠又拖慢测试 - 避免在测试函数末尾只调用
t.start()就返回 - 所有工作线程必须用
t.join(timeout=...)收尾，且 timeout 要设合理（比如 2–5 秒），防止死锁卡住 CI
用 threading.Event 和 threading.Lock 模拟真实竞态场景
想验证某个类/函数是否线程安全，得主动制造竞争条件。比如测试一个计数器类：Counter 的 increment() 方法是否被多个线程同时调用时仍能准确累加。
这时候不能只写 “开10个线程各加100次”，还得检查最终值是否等于 1000——但光比结果还不够，要确认中间状态有没有被破坏（比如出现负值、跳变）。所以建议配合 threading.Event 控制节奏，让所有线程在临界区前统一就位，再同时触发：
立即学习“Python免费学习笔记（深入）”；
def test_counter_thread_safety():
counter = Counter()
ready = threading.Event()
done = threading.Event()
<pre class="brush:php;toolbar:false;">def worker():
ready.wait() # 所有线程等信号
for _ in range(100):
counter.increment()
done.set()
threads = [threading.Thread(target=worker) for _ in range(10)]
for t in threads:
t.start()
ready.set() # 同时放开
for t in threads:
t.join(timeout=3)
assert counter.value == 1000
注意：ready 和 done 是为了增强竞态触发概率，不是必需，但能显著提升测试敏感度。
捕获线程内异常：sys.excepthook 不生效，得自己兜底
Python 中子线程抛出未捕获异常，默认不会中断主线程，也不会让 pytest 报错——它就静默消失了。你看到测试通过，其实某个线程已经崩了。
解决办法只有一个：在线程 target 函数里包一层 try/except，并把异常存起来，主线程最后统一 re-raise：
- 定义一个全局
thread_errors = []（或用queue.Queue） - 每个 worker 函数里
try: ... except Exception as e: thread_errors.append(e) - 所有
t.join()后，检查if thread_errors: raise thread_errors[0]
不要试图改 threading.excepthook——从 Python 3.8+ 开始它才支持，且 pytest 的捕获逻辑和它不兼容，容易漏报。
避免误判：共享资源初始化必须在多线程前完成
常见错误是把被测对象（比如一个 dict 或缓存实例）放在循环里创建，导致每个线程操作的是不同副本，根本没产生共享，自然“线程安全”。
例如这个错例：
# ❌ 错误：每个线程 new 自己的 cache
def worker():
cache = LRUCache(10)
cache.put("key", "val")
正确做法是把 cache = LRUCache(10) 放在测试函数开头，作为所有线程共享的 fixture 实例。
另一个易忽略点：如果被测代码内部用了模块级变量（如 import logging; logger = logging.getLogger(__name__)），那它天然跨线程共享——这时你要确认该 logger 是否线程安全（标准库 logging 是的，但自定义 handler 可能不是）。
真正难测的，永远是那些隐式共享的状态：文件句柄、全局计数器、单例里的 mutable 属性……这些地方不打日志、不加锁、不设断点，就很难定位到问题源头。
