C# 在异步操作之后立即调用Task.Wait（）是否等同于同步运行同一操作？

换句话说，就是

var task = SomeLongRunningOperationAsync();
task.Wait();

功能上与相同

SomeLongRunningOperation();

换句话说，就是

var task = SomeOtherLongRunningOperationAsync();
var result = task.Result;

功能上与相同

var result = SomeOtherLongRunningOperation();

根据，如果正在等待的任务已经开始执行，

Wait

必须阻止。但是，如果尚未开始执行，

Wait

可能能够将目标任务从其排队的计划程序中拉出，并在当前线程上内联执行

这两种情况是否仅仅是决定任务将在哪个线程上运行的问题，如果您仍在等待结果，这是否重要

---

如果异步调用和

Wait（）

之间没有执行任何操作，那么使用异步表单比使用同步表单有什么好处？

以下是一些区别：

计算可能在不同的线程上运行。如果此任务基于CPU并且可以内联，则它可能在同一线程上运行。这是不确定的

如果没有内联发生，则在计算过程中将使用一个或多个线程。这通常需要1MB的堆栈内存

异常将包装在

aggregateeexception

中。异常堆栈将不同

如果线程池已达到最大值，则如果要使任务完成，必须计划另一个任务，则可能会死锁

线程本地状态，如HttpContext.Current（实际上不是线程本地状态，但几乎是线程本地状态）可能不同

主线程的线程中止不会到达任务主体（内联情况除外）。我不确定等待本身是否会中止

创建一个

任务

会产生一个记忆障碍，它会产生同步效果

这有关系吗？根据这份清单自己决定

这样做有好处吗？我想不出有什么。如果您的计算使用异步IO，等待将否定异步IO带来的好处。一个例外是扇出IO，例如并行发出10个HTTP请求并等待它们。这样，您就可以以一个线程为代价执行10个操作

---

请注意，

Wait

和

Result

在所有这些方面都是等效的。

由于某个LongRunningOperation返回一些结果，我假设您的意思是

var Result=task.Result

task.Result是一个阻塞操作。无需

Wait（）

True。那为什么要等待呢？你说对了。不用了<代码>变量结果=任务结果就足够了。罗伯特，如果任务没有返回任何东西，你就要等待它。听起来风险并没有超过好处（如果有的话。你没有提到任何好处）。你期望什么好处？我不知道有什么，除非您明确希望列出任何行为。我在一些我没有编写的代码中发现了这一点，并假设一定有某种原因。但在我发现的代码中没有任何东西表明它需要这些行为，等待和结果是等价的。如果没有可用的同步版本，那么这是一个很好的理由，假设他出于某种原因真的想拥有一个同步操作模式（可能他正在实现一个接口）。在典型的ASP.NET代码中，这种阻塞很容易出现死锁。@TheodorZoulias我编辑了这篇文章。事实上，这是一个语言错误。谢谢你指出这一点。