我知道在任务中使用 Thread.Sleep 是一个愚蠢的想法，因为它会阻塞线程池中的那个线程。
但是，如果我有一个专用于某事的线程，由 new Thread(new ThreadStart(Foo)) 创建，Task.Delay 是否仍然有意义？无论如何都不会使用该线程。我也想知道 Task.Delay 会有什么确切的影响。它不会让线程休眠，所以它会充当自旋等待吗？那会比 sleep 更糟糕。不会吧？
最佳答案
我很难从问题中弄清楚这里的情况是什么；这似乎表明您正在分配一个线程，然后您希望它在一段时间内什么都不做。这是一件奇怪的事情，花钱让一个 worker 什么都不做。请说明情况。
回答您的具体问题:
It won't put the thread to sleep, so will it act as a spin wait?
没有。
That would be much worse then a sleep. Wouldn't it be?
是的，那会很糟糕!它将具有休眠线程的所有缺点，但会消耗功率并在此过程中产生热量。您不仅要支付分配线程的开销，您还会无益地浪费电力。您曾经唯一想要旋转等待的时间是当您正在等待将在比线程量程短得多的时间内发生的事情时。自旋等待纳秒或最坏情况，等待微秒，而不是毫秒。您想旋转等待需要几条指令的东西，而我们每秒运行数十亿条指令。
根据您的问题，我怀疑 (1) 您根本不了解 Task.Delay 的作用，以及 (2) 您分配了不必要的线程。
我们先来说说Task.Delay的作用。
Task.Delay 立即返回一个对象，表示延迟一定毫秒数的任务。
这就是它所做的一切。
真的。
它实际上不会延迟任何毫秒数。 它返回一个代表延迟概念的任务。确保你头脑清楚。
如果您询问任务是否完成，它当然会告诉您是否已经过了该秒数。
如果您分配一些函数作为该任务的延续，该延续将被安排在任务完成后的某个时刻在当前上下文中运行。
然后 await Task.Delay(whatever); 做了什么？
我只是说了它的作用。 Task.Delay 返回代表延迟的任务。 await 检查该任务是否完成。如果是，则程序将照常继续。如果任务未完成，则await 的位置成为任务的继续点，方法返回到其调用者。然后计划在任务完成后的 future 某个时间点在当前上下文中执行延续。
为什么你要雇用一名 worker 来做这件事，我不知道也不明白。雇用 worker 从事 CPU 密集型工作，他们在完成之前不会停止对 CPU 的敲击一纳秒。不要雇用 worker 做一次延迟几毫秒的事情，比如访问磁盘或延迟工作!
关于c# - Task.Delay 在专用线程上有意义吗？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/52863940/