ASP.NET 异步/等待第 2 部分

Question

我有一个来自 this question 的 async/await-on-ASP.NET 的好处的变体。

我的理解是异步与并行不是一回事。所以，在 Web 服务器上，我想知道 async/await 给 ASP.NET 页面带来了多少好处。

IIS+ASP.NET 不是已经非常擅长为请求分配线程了吗？如果一个页面忙于等待资源，服务器就会切换到处理另一个有工作要做的请求？

池中可供 ASP.NET 使用的线程数量有限 - async 是否更有效地使用它们？

正如 Skeet 先生在回答上述问题时指出的那样，我们并不是在谈论阻塞 UI 线程。我们已经是多线程的，在所有请求的任务都完成之前无法完成 Web 响应，无论是否异步，对吧？

我想归根结底是这样的：

在 ASP.NET 页面中异步读取资源（例如文件或 DB 请求）与阻塞它有什么好处？

Answer 1

如果一个页面忙于等待资源，服务器将切换到处理另一个有工作要做的请求？

我不这么认为。如果是这样的话，我会非常感到惊讶。理论上可行，但非常复杂。

池中可供 ASP.NET 使用的线程数量有限 - async 是否更有效地使用它们？

是的，因为当您await 某事时，该请求的线程会立即返回到池中。

我们已经是多线程的了，直到所有请求的任务都完成后才能完成网络响应，无论是否异步，对吧？

没错。服务器场景中的async 就是为了消除线程池的压力。

在 ASP.NET 页面中异步读取资源（例如文件或 DB 请求）与阻塞它有什么好处？

绝对！

如果您阻塞文件/服务调用/db 请求，则该线程将在该操作期间使用。如果您await 一个文件/服务调用/db 请求，那么该线程会立即返回到线程池。

这样做的一个（真的很酷！）结果是您可以有一个正在进行的请求，并且当它（a）等待某个操作时，没有 线程为该请求提供服务！零线程并发，如果你愿意的话。

当操作完成时，该方法在await 之后恢复 - 在线程池中的一个（可能不同的）线程上。

结论：async 的可扩展性比线程好，因此在服务器端肯定有好处。

更多信息：我自己的intro to async post 和this awesome video。