非异步方法中Thread.Sleep()与Task.Delay().Wait()的优劣探讨

背景说明 #

原有非异步方法中用Thread.Sleep(500)实现延迟，同事重构为Task.Delay(500).Wait()。这段代码用于API请求外部服务的重试轮询逻辑（会尝试3-5次），运行在平均每分钟执行一次的后台进程；因当前方法为非异步故未使用await，同事在异步方法中会正常用await而非.Wait()。

1. 短延迟场景下用Task.Delay()有优势吗？延迟时长会影响结论吗？ #

• 短延迟（比如几百毫秒）：没优势，甚至更差。Thread.Sleep()直接让当前线程进入阻塞状态，调度开销极低；而Task.Delay()依赖定时器触发，还要经过线程池调度，短延迟下这点调度成本的占比会很高，反而不如Thread.Sleep()高效。
• 延迟时长变化：如果延迟拉长到几秒以上，Task.Delay()本身的优势（不阻塞线程，线程可被复用）会显现，但前提是用await而非.Wait()。如果还是用.Wait()同步等待，不管延迟多久，Task.Delay().Wait()都不如Thread.Sleep()——因为多了一层异步调度的开销，线程照样被阻塞，完全没用到异步的好处。

2. .Wait()是否违背异步设计初衷？ #

完全违背。异步设计的核心是释放当前线程，让它可以去处理其他任务，避免线程阻塞浪费资源。而.Wait()会强制当前线程同步等待Task完成，相当于把异步调用又拉回了同步阻塞的模式：线程还是被卡住啥也干不了，异步的优势一点没发挥，还平白多了异步调度的额外开销。

3. 后台进程每分钟执行一次，第二种方式会浪费更多资源吗？ #

从资源消耗来说，确实会多消耗一点，但因为执行频率极低（每分钟一次，每次重试3-5次，每次延迟500ms），这点浪费几乎可以忽略不计。但从代码合理性来说，完全没必要这么做：

• 既然是同步方法，直接用Thread.Sleep()更简单高效，没有额外的异步调度开销；
• 如果想真正利用异步的优势，应该把整个方法改成异步，用await Task.Delay()，而不是用.Wait()强行把异步改成同步。

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