asp.net-mvc - ASP.NET 的异步和 CPU 绑定(bind)操作

Question

async 因 ASP.NET 而受到称赞的原因之一是遵循 Nodejs 异步平台，这通过释放线程来处理后续请求等带来了更大的可扩展性。

但是，我已经读到在 Task.Run 中包装 CPU 绑定(bind)代码会产生相反的效果，即为服务器增加更多开销并使用更多线程。

显然，只有真正的异步操作才会受益，例如发出网络请求或调用数据库。

所以，我的问题如下。关于操作方法何时应该异步，是否有明确的指导？

Answer 1

Mr Cleary is the one who opined about the fruitlessness of wrapping CPU-bound operations in async code.

不完全是，在 ASP.NET 应用程序中包装 CPU 绑定(bind)异步代码与在 - 例如 - WPF 桌面应用程序中执行此操作之间存在差异。让我用你的这个陈述来建立我的答案。

您应该将脑海中的异步操作(以最简单的形式)分类如下:

ASP.NET 异步方法，其中包括:

CPU 密集型操作，

阻塞操作，例如 IO 操作

直接面向用户的应用程序中的异步方法，其中包括:

CPU 密集型操作，

和阻塞操作，例如 IO 操作。

我假设通过阅读 Stephen Cleary 的帖子，您已经了解异步操作的工作方式是，当您执行 CPU 密集型操作时，该操作将传递给线程池线程，并在完成后，程序控制返回到它开始的线程(除非你调用 .ConfigureAwait(false))。当然，这只发生在确实有异步操作要做的情况下，正如我在 this question 中也想知道自己的情况一样。 .

另一方面，当谈到阻塞操作时，情况有点不同。在这种情况下，当异步执行代码的线程被阻塞时，运行时会注意到它，并“挂起”该线程正在完成的工作:保存所有状态以便稍后继续，然后该线程用于执行其他操作。当阻塞操作准备好时——例如，网络调用的答案已经到达——然后(我不完全知道它是如何被运行时处理或注意到的，但我试图为你提供一个高级解释，因此不是绝对必要的)运行时知道您发起的操作已准备好继续，状态已恢复并且您的代码可以继续运行。

综上所述，两者之间有一个重要的区别:

在 CPU 密集型的情况下，即使您异步启动操作，也会出现 是 工作要做，您的代码不必等待任何事情。

但是，在 IO 绑定(bind)情况或阻塞情况下，您的代码可能需要一段时间 除了等待，什么也做不了 因此，您可以在使用它的同时释放在该点之前完成处理的线程并执行其他工作(可能处理另一个请求)，这很有用。

对于直接面向用户的应用程序，例如 WPF 应用程序，如果您在主线程(GUI 线程)上执行长时间运行的 CPU 操作，那么 GUI 线程显然很忙，因此显得无响应对用户，因为任何互动， 通常由 GUI 线程处理 只是在消息队列中排队，直到 CPU 密集型操作完成后才会被处理。

但是，对于 ASP.NET 应用程序， 这不是问题 ，因为应用程序并不直接面向用户，所以他看不到它是无响应的。为什么将工作委托(delegate)给另一个线程没有任何好处是因为这仍然会占用一个线程，否则可以做其他工作，因为，好吧，任何需要做的事情都必须完成，它只是不能神奇地完成你。

可以这样想:你和一个 friend 在厨房里(你和你的 friend 是一对一的)。你们两个正在准备点菜。你可以叫你的 friend 把洋葱切丁，即使你摆脱了切洋葱的麻烦，可以处理肉的调味，但你的 friend 却忙于切洋葱，所以他不能同时做肉的调味。如果你没有把切洋葱的工作委托(delegate)给他(你已经开始了)而是让他做调味，同样的工作也会完成，只是你会节省一点时间，因为你不会需要交换工作环境(本例中的砧板和刀具)。简而言之，您只是通过交换上下文造成了一些开销，而无响应问题对用户来说是不可见的。 (只要他收到结果，客户既不会看到也不会关心你们中的谁在做什么工作)。

话虽如此，我在顶部概述的分类可以通过将 ASP.NET 应用程序替换为“任何应用程序对用户没有直接可见的界面，因此不会对他们没有响应”进行改进。