异步等待和 Task.Run 问题

Question

我需要知道这些记录有什么不同，如果有，它们是什么？ 这对我来说相当困难：

1) Task.Run(async () => { await CheckVerification(); });
2) Task.Run(() => CheckVerification());
3) await Task.Run(async () => { await CheckVerification(); });

Answer 1

如果我们暂时忘记Task.Run，也许更容易理解其中的区别。您的第 1 点和第 2 点之间的区别与等待或仅从 Task 返回方法返回内部任务基本相同：

// 1)
public async Task WithAwait() => await SomeOtherTaskReturningMethod();

// 2)
public Task WithoutAwait() => return SomeOtherTaskReturningMethod();

第一个创建另一个任务，它包装了内部的任务，这是一个很小的开销，但是这两种方法在功能上几乎相同。一个小的区别是当SomeOtherTaskReturningMethod 抛出异常时，内部任务的AggregatedException 将被解包，并且（第一个）内部异常将被进一步抛出。当然，事情仍然取决于外部任务发生了什么。在您的第三点中，它也处于等待状态，因此您将从外部任务（如果有）中获得未包装的异常，而第一个和第二个示例只是一劳永逸。

现在让我们再次考虑Task.Run。主要问题为什么这个方法有重载，接受Tasks（实际上是Task返回回调），当你也可以简单地调用await CheckVerification();并得到相同的结果？ （我知道这不是问题的一部分，但可能值得澄清一下）

所以存在这种Task.Run 重载的原因是Task 返回方法本身不一定在另一个线程上执行（我建议this reading）。例如，它可以只通过网络套接字发送一条消息并返回一个Task，这将在收到特定答案时完成。这使得操作异步，仍然不是多线程的。

如果您有这样的任务，并且希望强制它在另一个线程上执行，那么您可以通过Task.Run 执行它，它使用默认调度程序并最终在池线程上执行您的任务。

值得一提的是，这是一种非常罕见的情况。在大多数情况下，您应该依赖 Task 返回方法的内部实现。

TL;DR：

所以我认为真正的问题是是否

await CheckVerification();

或

await Task.Run(() => CheckVerification());

是更好的解决方案（或者可能是其中之一没有await，即即发即弃模式）。在大多数情况下，我会投票给第一个，但如果您真的确信CheckVerification 返回的任务必须分配给一个池线程（无论它是否在内部执行），那么第二个选项也可以是合理的.

Answer 2

1) 开始一个任务。该任务将等待内部的方法，但是是异步的，因此您的 UI 或调用线程不会阻塞。

2) 启动一个任务，它启动另一个任务。一切都是异步运行的，没有任何等待，完全触发并忘记。

3) 将启动一个任务，该任务启动一个方法并等待它，返回执行上下文，让调用线程以其等待放弃执行上下文，让调用此的方法继续执行，直到它等待它方法。