等待vs Task.Wait-死锁？

我不太明白之间的差别Task.Wait和await。

我在ASP.NET WebAPI服务中具有类似于以下功能的内容：

public class TestController : ApiController
{
    public static async Task<string> Foo()
    {
        await Task.Delay(1).ConfigureAwait(false);
        return "";
    }

    public async static Task<string> Bar()
    {
        return await Foo();
    }

    public async static Task<string> Ros()
    {
        return await Bar();
    }

    // GET api/test
    public IEnumerable<string> Get()
    {
        Task.WaitAll(Enumerable.Range(0, 10).Select(x => Ros()).ToArray());

        return new string[] { "value1", "value2" }; // This will never execute
    }
}

哪里Get将陷入僵局。

是什么原因造成的？为什么在我使用阻塞等待而不是时这不会引起问题await Task.Delay？

Wait和await-而概念上类似于-实际上是完全不同的。

Wait将同步阻止，直到任务完成。因此，当前线程实际上被阻塞，等待任务完成。通常，应使用“ async一直向下”；也就是说，不要阻塞async代码。在我的博客上，我详细介绍了异步代码中的阻塞如何导致死锁。

await将异步等待，直到任务完成。这意味着当前方法已“暂停”（已捕获其状态），并且该方法向其调用者返回了未完成的任务。稍后，当await表达式完成时，将该方法的其余部分安排为继续。

您还提到了“合作块”，我假设您的意思是您正在Wait执行的任务可以在等待的线程上执行。在某些情况下可能会发生这种情况，但这是一种优化。在许多情况下，它不可能发生，例如，该任务是用于另一个调度程序的，还是已经启动的，或者它是非代码任务的（例如，在您的代码示例中：由于没有代码，所以Wait无法Delay内联执行任务）为了它）。

您可能会发现我的async/ await介绍很有帮助。

根据我从不同来源所读到的内容：

一个await表达式不阻止它在其上执行线程。而是，它使编译器将async方法的其余部分注册为已完成任务的延续。控制然后返回到async方法的调用者。任务完成后，它将调用其继续，并执行async方法的将从中断处继续。

要等待单曲task完成，可以调用其Task.Wait方法。致电Wait方法的调用阻塞调用线程，直到单个类实例完成执行为止。无参数Wait()方法用于无条件等待直到任务完成。该任务通过调用Thread.Sleep方法睡眠两秒钟来模拟工作。

这篇文章也是不错的阅读。

其他答案未提供一些重要事实：

在CIL级别上，“异步等待”更为复杂，因此会花费内存和CPU时间。

如果等待时间不可接受，则可以取消任何任务。

在“异步等待”的情况下，我们没有此类任务的处理程序来取消或监视它。

使用“任务”比“异步等待”更为灵活。

任何同步功能都可以由异步包装。

public async Task<ActionResult> DoAsync(long id) 
{ 
    return await Task.Run(() => { return DoSync(id); } ); 
} 

我不明白为什么我必须忍受同步和异步方法的代码复制或使用黑客手段。