ASP.NET MVC中的异步控制器：真正的优势/如何实现？

我一直在阅读有关ASP.NET MVC中异步控制器方法的文章（http://visualstudiomagazine.com/articles/2013/07/23/async-actions-in-aspnet-mvc-4.aspx），我认为我可能错过了重点。

考虑一下我写的这种方法，它与文章中的示例非常相似：

[HttpGet]
[AsyncTimeout(8000)]
[HandleError(ExceptionType = typeof(TimeoutException), View = "TimedOut")]
public async Task<ActionResult> Index(CancellationToken cancellationToken)
{
    WidgetPageViewModel model = new WidgetPageViewModel()
    {
        toAdd = new Widget()
    };
    model.all = await _repo.GetAllAsync(cancellationToken);
    return View(model);
}

据我了解，这是运行时事物将如何展开的方式：

1. 将为传入的HTTP请求创建一个ASP.NET线程。

2. 该线程将（已经完成了一些必要的初步工作）输入上述我的Index（）方法。

3. 执行将到达“ await”关键字，并在另一个线程上启动数据获取过程。

4. 原始的“ ASP.NET”线程将返回调用我的处理程序方法的代码，并将Task类的实例作为返回值。

5. 调用我的处理程序方法的基础结构代码将继续在原始的“ ASP.NET”线程上运行，直到达到需要使用实际ActionResult对象（例如，呈现页面）的程度。

6. 然后，调用者将使用Task.Result成员访问此对象，这将使它（即“ ASP.NET”线程）等待上述步骤3中隐式创建的线程。

与没有等待/异步的同一件事相比，我看不到这完成了什么，除了我认为是琐碎的两件事：

• 由await创建的调用者线程和工作线程可以并行运行一段时间（上述＃5的“直到”部分）。我的预感是这段时间很小。当基础结构调用控制器方法时，我认为它通常需要控制器调用的实际ActionResult才能做更多（如果有的话）。

• 有一些有用的新基础结构与超时和取消长时间运行的异步控制器操作有关。

添加异步控制器方法的目的应该是释放那些ASP.NET辅助线程以实际响应HTTP请求。这些线程是有限的资源。不幸的是，我没有看到文章中建议的模式实际上如何用于保存这些线程。即使这样做，并且以某种方式将处理请求的负担转移到了一些非ASP.NET线程上，那又完成了什么呢？碰巧能够处理HTTP请求的线程与一般线程有很大不同吗？

不使用任务并行库（TPL）的ASP.Net受线程池中的线程数限制，它可以同时处理的请求数。使用TPL的ASP.Net受到计算机处理请求的CPU /内存/ IO的限制。

任务并行库（TPL）不会像您认为的那样消耗线程。任务不是线程，它们是某些计算单元的包装。任务计划程序负责在不繁忙的任何线程上执行每个任务。在运行时，等待任务不会阻塞线程，它只是驻留执行状态，以便它可以在以后的时间继续执行。

通常，单个HTTP请求将由单个线程处理，从池中完全删除该线程，直到返回响应。使用TPL，您不受此约束的约束。传入的任何请求都会以计算所需的每个计算单位开始继续，以计算能够在池中的任何线程上执行的响应。使用此模型，与标准ASP.Net相比，您可以处理更多的并发请求。