Sonar为何建议避免使用Thread.sleep？改用Awaitility的原因是什么？

核心逻辑是：Thread.sleep是无脑硬等固定时长，而Awaitility的写法是智能等待目标条件满足——这才是规则要求替换的核心原因，和后台是否创建线程完全无关。具体拆解如下：

1. Thread.sleep的两大硬伤 #

• 效率极低：不管你等待的异步操作、状态变更是否已经完成，它都会睡满设定的时间。比如某个接口调用100ms就返回了，但你写了Thread.sleep(2000)，平白多等1.9秒，测试套件跑多了，整体耗时会被拖得很长。
• 稳定性差：如果因为环境波动（比如测试服务器负载高），目标操作耗时超过了你设定的sleep时长，测试就会失败——这种失败不是代码逻辑有问题，是等待时间设短了，属于无意义的不稳定因素。

2. Awaitility的核心优势 #

await().atMost(2, Duration.SECONDS).until(didTheThing())的逻辑是：

• 它会定期检查didTheThing()返回的条件（默认间隔100ms，可自定义），一旦条件满足，立刻结束等待，不会浪费多余时间。
• atMost(2, SECONDS)给等待加了超时上限，防止因为条件永远不满足导致无限等待，既保证了效率，又给了足够的容错空间。

另外，可读性和维护性也远胜Thread.sleep：别人看Thread.sleep(2000)根本不知道你在等什么，但看until(didTheThing())，一眼就能明白是在等某个业务操作完成、状态变更或者异步任务结束。

3. 关于“Awaitility也创建线程”的疑问 #

没错，Awaitility内部确实会用到线程处理调度逻辑，但这完全不是重点——规则要解决的根本问题是等待逻辑的合理性，而非要不要用线程。

Thread.sleep是让当前测试线程直接阻塞死等，而Awaitility的等待是基于业务条件的主动轮询等待，两者的逻辑模式天差地别。哪怕Awaitility用了线程，它带来的效率提升、稳定性保障、代码可读性优势，都是Thread.sleep无法比拟的。

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