await Task.Delay() 和 Task.Delay().Wait() 在单独的任务中是否存在性能差异？

Question

我有一个这样的构造：

Func<object> func = () =>
{
    foreach(var x in y)
    {
        ...
        Task.Delay(100).Wait();
    }
    return null;
}
var t = new Task<object>(func);
t.Start(); // t is never awaited or waited for, the main thread does not care when it's done.
...

所以基本上我创建了一个调用Task.Delay(100).Wait()很多次的 function func 。 我知道一般不鼓励使用.Wait() 。 但我想知道展示的案例是否有具体的性能损失。

.Wait()调用发生在一个单独的任务中，它完全独立于主线程，即它永远不会等待或等待。 我很好奇当我以这种方式调用Wait()时会发生什么，以及我机器的处理器上会发生什么。 在等待的 100 毫秒内，处理器内核能否执行另一个线程，并在时间过去后返回 Task？ 还是我只是产生了一个繁忙的等待过程，我的 CPU 在 100 毫秒内“主动无所事事”，从而减慢了我的程序的 rest？

与我将其设为异步 function 并调用await Task.Delay(100)的解决方案相比，这种方法是否有任何实际的缺点？ 这对我来说是一个选择，但如果可以合理避免，我宁愿不使用 go。

Answer 1

由于线程的低效使用，存在具体的效率损失。 每个线程的堆栈至少需要1 MB ，因此为了什么都不做而创建的线程越多，为非生产性目的分配的 memory 就越多。

如果线程需求超过ThreadPool可用性，也可能会出现具体的性能损失。 在这种情况下， ThreadPool变得饱和，新线程以保守（缓慢）的速率注入池中。 因此，您创建和Start的任务不会立即开始，而是会进入一个内部队列，等待一个空闲线程，要么是完成了一些先前工作的线程，要么是一个新注入的线程。

关于您对创建繁忙的等待程序的担忧，不，这不是正在发生的事情。 休眠线程不消耗 CPU 资源。

附带说明一下，使用Task构造函数创建冷Task是一种高级技术，仅用于特殊场合。 创建基于委托的任务的常用方法是通过方便的Task.Run方法，该方法返回热（已启动）任务。