RSpec线程中并发API调用测试问题：多线程创建员工接口竞态条件验证失败排查

看起来你在测试并发创建员工的竞态条件时，遇到了线程没有全部触发API请求的问题，导致测试偶尔失败。我来帮你分析几个可能的原因和对应的解决方案：

1. 线程同步机制不可靠 #

你当前用true while wait的忙等方式来同步线程，这里存在两个核心问题：

• 内存可见性问题：Ruby线程共享内存，但CPU缓存可能导致部分线程无法及时感知wait变量的变化，一直卡在循环里。
• 忙等占用资源：这种循环会持续占用CPU，导致线程调度延迟，部分线程没来得及执行submit_request就被主线程join了。

改进方案：使用ConditionVariable做可靠同步 #

用Ruby的Mutex和ConditionVariable来替代忙等，能更精准地唤醒所有线程：

def threaded_api_request(example)
  mutex = Mutex.new
  cond = ConditionVariable.new
  wait = true

  threads = 4.times.map do |i|
    Thread.new do
      mutex.synchronize do
        # 等待信号，直到wait变为false
        cond.wait(mutex) while wait
      end
      # 捕获线程内的异常，避免静默失败
      begin
        submit_request example.metadata
      rescue => e
        puts "线程 #{i} 执行失败: #{e.message}"
        raise e # 重新抛出异常，让测试能感知到失败
      end
    end
  end

  # 唤醒所有等待的线程
  mutex.synchronize do
    wait = false
    cond.broadcast
  end

  threads.each(&:join)
end

2. 线程内异常未捕获 #

如果submit_request在执行过程中抛出异常（比如数据库唯一约束冲突、网络问题等），线程会静默终止，不会创建员工记录，但你无法感知到这个错误。上面的改进代码中已经加入了异常捕获，能帮你定位到具体的失败原因。

3. API请求逻辑的竞态问题 #

即使线程都执行了API请求，也可能因为业务逻辑的竞态导致创建失败：比如多个线程同时查询当前最大的employee_code后缀，生成相同的新代码，触发数据库唯一约束异常。这时候需要确保生成唯一代码的逻辑是原子性的：

• 可以在数据库层面用SELECT ... FOR UPDATE锁定查询结果，避免其他线程读取到旧数据；
• 或者使用数据库的序列、触发器来自动生成唯一后缀，把逻辑转移到数据库层，避免应用层的竞态。

4. RSpec钩子执行顺序检查 #

你的测试中有多个before钩子，要确保threaded_api_request是在所有准备工作（比如Time.zone的mock）之后执行的。另外，检查submit_request是否正确使用了example.metadata，如果参数传递错误，可能导致请求没有正确发送。

5. 数据库清理策略验证 #

虽然你配置了DatabaseCleaner的截断策略，但可以确认下测试前后数据库是否被正确清理，避免残留数据影响测试结果。另外，确保use_transactional_fixtures: false的配置生效，因为事务会隔离线程间的数据库操作，导致其他线程看不到彼此的修改。

通过以上几点调整，应该能解决线程未全部执行API请求的问题，让你的并发测试更稳定。

内容的提问来源于stack exchange，提问作者SujoyD