什么时候应该在 Asp.Net Core 中使用 Task.Run？答案

【问题标题】：When should I use Task.Run in Asp.Net Core?什么时候应该在 Asp.Net Core 中使用 Task.Run？
【发布时间】：2018-07-10 02:38:55
【问题描述】：

我相信您永远不必在 .net 核心 Web 上下文中使用 Task.Run 进行任何操作。如果您有一个长时间运行的任务或 CPU 密集型任务，您可以将其卸载到消息队列以进行异步处理。如果你有一个同步操作，它没有等效的异步方法，那么卸载到后台线程对你没有任何帮助，它实际上会变得更糟。

我错过了什么？在高吞吐量服务器应用程序中使用 Task.Run 是否有真正的理由？

【问题讨论】：

【解决方案1】：

一些简单的例子：

【讨论】：

感谢您的回复！我们不能为数字 3 使用IHostedService 来安排任务吗？对我来说，第 4 号也是我想过的，因为我每天可能会这样做。对于 6 号，我们需要Task.Run 还是应该这样做？ (stackoverflow.com/questions/45013054/…)
这些是回答您问题的示例。如果您对任何特定项目有疑问，请发布单独的问题。很抱歉，我不会花时间和你详细讨论整个列表。
我没想到你会和我一起讨论任何事情，这更像是对你的例子的回答，为什么我们仍然不需要 Task,Run。
5.在 ASP.NET Core 上下文中非常愚蠢。当您在响应完成后运行某些东西时，您只是自找麻烦，因为作用域服务在请求结束时被释放，但如果您的代码仍然运行，它会为ObjectDiposedException 大喊大叫。 4 不适用，问题是关于高吞吐量服务器应用程序。
@Tseng 我觉得愚蠢的是解决方案是搜索问题，这就是这里的上下文。列表的重点是展示异步+单线程同步代码无法解决的情况，而不是针对想象中的问题提供完整正确的解决方案。

【解决方案2】：

只是为了支持你的信念：

不要：调用 Task.Run 并立即等待它。 ASP.NET Core 已经在普通线程池线程上运行应用程序代码，因此调用 Task.Run 只会导致额外的不必要的线程池调度。即使计划的代码会阻塞线程，Task.Run 也不会防止这种情况发生。

这是官方recommendation/best practice from Microsoft。虽然它没有指出您可能遗漏了什么，但它确实告诉您这是一个坏主意以及原因。

【讨论】：