我应该总是使用Task.Delay而不是Thread.Sleep吗？
我最近看到几条建议说明Thread.Sleep永远不应该用在生产代码中（最近在这个SO问题中 ）。 其中许多人主张使用Task.Delay 。 我发现的大多数解释都使用UI应用程序作为示例，因为Task.Delay的优点是显而易见的（不阻止UI）。
在我的例子中，我在一个等待循环中使用Thread.Sleep来轮询WCF服务的特定条件，如下所示：
DateTime end = DateTime.UtcNow + TimeSpan.FromMinutes(2); while (DateTime.UtcNow < end) { if (ExternalServiceIsReady() == true) { return true; } Thread.Sleep(1000); }
在这种情况下， Task.Delay的以下潜在优势似乎不适用：
- 睡眠时间相对于大约15毫秒的典型定时器分辨率相当大，因此
Task.Delay准确性增加似乎微不足道。 - 该进程是单线程（非UI），必须阻塞直到条件为真，因此使用
await在这里没有优势。 - 不需要取消延迟的能力。
这是一个适合使用Thread.Sleep吗？ 用Task.Delay(1000).Wait()替换我的睡眠线会有什么好处（如果有的话） Task.Delay(1000).Wait() ？
替换Thread.Sleep(1000);永远不会有优势Thread.Sleep(1000); 在Task.Delay(1000).Wait(); 。 如果要同步等待，只需使用Thread.Sleep 。
如果你真的只有一个线程并计划保持这种方式，那么你可以使用Thread.Sleep 。 但是，在大多数情况下，我仍然会使用Task.Delay ，因此它是一个很好的模式。 当你不能再使用async时，我只会阻止在顶部，即便如此，我建议使用某种AsyncContext 。
您也可以直接使用System.Threading.Timer *而不是Task.Delay但是您应该记住，计时器执行每个时间间隔并且不等待实际操作完成，因此如果ExternalServiceIsReady需要超过您的间隔时间可以同时多次调用该服务。
一个更好的解决方案是用异步操作替换外部服务的轮询，这样服务就可以在它准备就绪时通知你而不是你每秒都要求它（这并不总是可能，因为它取决于服务）：
await ExternalServiceIsReadyAsync();
* Task.Delay在内部使用System.Threading.Timer ，其分辨率约为15ms。