我想补充一点。 实际上,任务。Delay是一种基于定时器的等待机制。如果您查看源代码，您会发现一个Timer类的引用，它是造成延迟的原因。另一方面，线程。Sleep实际上使当前线程休眠，这样你只是阻塞和浪费了一个线程。在异步编程模型中，如果你想在延迟后发生某些事情(延续)，你应该总是使用Task.Delay()。

如果当前线程被杀死，你使用thread。Sleep并且它正在执行，那么你可能会得到一个ThreadAbortException。 与任务。延迟您总是可以提供一个取消令牌并优雅地终止它。这就是我选择Task.Delay的原因之一。参见http://social.technet.microsoft.com/wiki/contents/articles/21177.visual-c-thread-sleep-vs-task-delay.aspx

我也同意在这种情况下效率不是最重要的。

我想补充一点。 实际上,任务。Delay是一种基于定时器的等待机制。如果您查看源代码，您会发现一个Timer类的引用，它是造成延迟的原因。另一方面，线程。Sleep实际上使当前线程休眠，这样你只是阻塞和浪费了一个线程。在异步编程模型中，如果你想在延迟后发生某些事情(延续)，你应该总是使用Task.Delay()。

我的观点,

Task.Delay()是异步的。它不会阻塞当前线程。您仍然可以在当前线程中执行其他操作。它返回一个Task返回类型(Thread.Sleep()不返回任何东西)。您可以检查该任务是否已完成(使用task。IsCompleted属性)，稍后在另一个耗时的过程之后。

Thread.Sleep()没有返回类型。它是同步的。在线程中，除了等待延迟完成之外，您实际上不能做任何事情。

至于在现实生活中的使用，我已经编程15年了。我从未在产品代码中使用过Thread.Sleep()。我找不到任何用例。 也许是因为我主要从事web应用程序开发。

值得一提的是Thread.Sleep(1)将更快地触发GC。

This is purely based mine & team member observations. Lets assume that you have service which creates new task every for specific request (approx. 200-300 ongoing) and this task contains many weak references in flow. The task is working like state machine so we were firing the Thread.Sleep(1) on change state and by doing so we managed to optimize utilization of memory in the application - like I said before - this will makes GC to fire faster. It doesn't make so much difference in low memory consumption services (<1GB).

是的，对于何时使用Task有一些一般的指导方针。Delay vs . Thread.Sleep。的任务。延迟是c#中异步编程的首选方法，因为它允许您在不阻塞线程的情况下异步等待。线程。Sleep阻塞调用线程，并可能导致高并发性应用程序的性能问题。

Task没有最小值。延迟对Thread.Sleep有效。一般来说，如果你需要等待一定的时间，最好使用Task.Delay。如果你需要在特定的时间内阻塞一个线程，请使用thread . sleep。

至于使用Task的开销。在异步/等待状态机中，上下文切换涉及一些开销。但是，开销通常很小，而且异步编程的好处远远超过了它。当使用Task。正确地延迟，它可以帮助提高应用程序的响应性和可伸缩性。