pytest不支持直接测试多线程竞态，因其单线程执行机制无法感知子线程状态，需显式同步（如join、Event）、避免sleep、在单个测试内复现竞态，并通过重试和重置状态提高暴露概率。
pytest本身不支持直接测试多线程竞态
pytest 是单线程执行框架，它不会自动同步、等待或感知子线程的执行状态。如果你在 test_* 函数里启动多个线程并期望它们“竞争”，pytest 很可能在主线程结束时就退出，导致子线程被静默终止，根本测不到竞态行为。
常见错误现象：AssertionError 没出现、断言通过但实际逻辑已出错、测试随机通过/失败（flaky test）、甚至完全不触发竞争路径。
- 必须显式等待所有工作线程完成（比如用
thread.join()） - 不能依赖 pytest 的默认生命周期管理线程资源
- 避免在测试中使用
time.sleep()做同步——它不可靠且拖慢测试
用 threading.Event 或 queue.Queue 控制竞态触发时机
要稳定复现竞态（比如两个线程同时修改同一个共享变量），关键不是“快”，而是“精确控制谁在什么时候读/写”。threading.Event 是最轻量的同步原语，适合做“起跑枪”。
示例场景：测试一个非线程安全的计数器类，在无锁情况下被两个线程各加 100 次，预期结果应为 200，但常因竞态变成 199 或更少：
立即学习“Python免费学习笔记（深入）”；
macOS UI 自动化技能包 —— 用 Python 控制你的 Mac
下载
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
import threading
import pytest
<p>def test_counter_race():
counter = Counter()
start_event = threading.Event()
done_event = threading.Event()</p><pre class="brush:php;toolbar:false;">def worker():
start_event.wait() # 等待统一指令
for _ in range(100):
counter.inc()
done_event.set()
t1 = threading.Thread(target=worker)
t2 = threading.Thread(target=worker)
t1.start(); t2.start()
start_event.set() # 同时放开两个线程
t1.join(); t2.join()
assert counter.value == 200 # 这里大概率失败
用 pytest-xdist 跑并发测试反而会掩盖问题
pytest-xdist 的 -n 参数是让多个 pytest 进程并行跑不同测试函数，不是让一个测试内部并发。它对检测线程竞态毫无帮助，反而可能因进程隔离让你误以为“没竞态”——因为每个测试都在独立进程中运行。
- 想暴露竞态，必须在**单个测试函数内**启动多个线程操作**同一内存对象**
-
pytest-xdist适合加速 I/O 类测试，不适合验证线程安全 - 如果测试本身依赖全局状态（如模块级变量、单例），
pytest-xdist可能引发不可预测的干扰
真正有效的做法：结合 assert + 重试 + 多次运行
竞态本质是概率性问题。一次运行没出错，不代表没 bug。你需要让测试“主动施压”：
- 把竞态循环次数提高到 1000+，增大暴露概率
- 用
for _ in range(5):包裹整个测试逻辑，失败时重试（注意重置状态） - 配合
pytest-repeat插件（--count=10）反复执行同一测试 - 在 CI 中强制开启
--count=50，把 flaky 测试变成“必现”
最易忽略的一点：所有共享对象（如 Counter 实例）必须在每次重试前重新构造，否则残留状态会让结果失真。
