ASP.NET MVC 中的异步操作使用 .NET 4 上的 ThreadPool 中的线程

这是一个excellent article，我建议您阅读以更好地理解 ASP.NET 中的异步处理（这是异步控制器基本上代表的内容）。

让我们首先考虑一个标准的同步动作：

public ActionResult Index()
{
    // some processing
    return View();
}

当对该操作发出请求时，将从线程池中提取一个线程，并在该线程上执行该操作的主体。因此，如果此操作中的处理速度很慢，则您将阻塞该线程以进行整个处理，因此该线程无法重用于处理其他请求。在请求执行结束时，线程返回到线程池。

现在让我们以异步模式为例：

public void IndexAsync()
{
    // perform some processing
}

public ActionResult IndexCompleted(object result)
{
    return View();
}

当向 Index 操作发送请求时，将从线程池中抽取一个线程并执行 IndexAsync 方法的主体。一旦这个方法的主体完成执行，线程就会返回到线程池。然后，使用标准 AsyncManager.OutstandingOperations，一旦您发出异步操作完成的信号，就会从线程池中提取另一个线程，并在其上执行 IndexCompleted 操作的主体，并将结果呈现给客户端。

所以我们在这个模式中可以看到，一个客户端 HTTP 请求可以由两个不同的线程执行。

现在有趣的部分发生在 IndexAsync 方法中。如果您在其中有一个阻塞操作，那么您完全浪费了异步控制器的全部目的，因为您阻塞了工作线程（请记住，此操作的主体是在从线程池中提取的线程上执行的）。

那么我们什么时候才能真正利用异步控制器，你可能会问呢？

恕我直言，当我们进行 I/O 密集型操作（例如对远程服务的数据库和网络调用）时，我们可以获得最大收益。如果你有一个 CPU 密集型操作，异步操作不会给你带来太多好处。

那么为什么我们可以从 I/O 密集型操作中获益呢？因为我们可以使用 I/O Completion Ports。 IOCP 非常强大，因为您在整个操作的执行过程中不会消耗服务器上的任何线程或资源。

它们是如何工作的？

假设我们要使用 WebClient.DownloadStringAsync 方法下载远程网页的内容。您调用此方法将在操作系统中注册一个 IOCP 并立即返回。在整个请求的处理过程中，您的服务器上不会消耗任何线程。一切都发生在远程服务器上。这可能需要很多时间，但您并不在意，因为您不会危及您的工作线程。一旦收到响应，就会发出 IOCP 信号，从线程池中提取一个线程并在该线程上执行回调。但是如你所见，在整个过程中，我们并没有独占任何线程。

FileStream.BeginRead、SqlCommand.BeginExecute 等方法也是如此。

并行化多个数据库调用怎么样？假设您有一个同步控制器操作，其中您按顺序执行了 4 个阻塞数据库调用。很容易计算，如果每个数据库调用需要 200 毫秒，那么您的控制器操作将需要大约 800 毫秒来执行。

如果您不需要按顺序运行这些调用，并行化它们会提高性能吗？

这是个大问题，不容易回答。可能是，可能不是。这完全取决于您如何实现这些数据库调用。如果您使用前面讨论的异步控制器和 I/O 完成端口，您将提高此控制器操作和其他操作的性能，因为您不会垄断工作线程。

另一方面，如果您执行得不好（在线程池中的线程上执行阻塞数据库调用），您基本上会将执行此操作的总时间降低到大约 200 毫秒，但您会消耗 4 个工作线程，所以您可能已经降低了其他请求的性能，这些请求可能由于池中缺少处理它们的线程而变得饥饿。

所以这是非常困难的，如果您还没有准备好对您的应用程序执行广泛的测试，请不要实现异步控制器，因为您可能会弊大于利。仅当您有理由这样做时才实施它们：例如，您已经确定标准同步控制器操作是您的应用程序的瓶颈（当然，在执行广泛的负载测试和测量之后）。

现在让我们考虑您的示例：

public ViewResult Index() { 

    Task.Factory.StartNew(() => { 
        //Do an advanced looging here which takes a while
    });

    return View();
}

当收到对 Index 操作的请求时，会从线程池中抽取一个线程来执行其主体，但其主体仅使用 TPL 调度一个新任务。所以动作执行结束，线程返回线程池。除此之外，TPL 使用线程池中的线程来执行它们的处理。所以即使原来的线程被返回到线程池中，你还是从这个池中抽取了另一个线程来执行任务的主体。因此，您从宝贵的池中危及了 2 个线程。

现在让我们考虑以下内容：

public ViewResult Index() { 

    new Thread(() => { 
        //Do an advanced looging here which takes a while
    }).Start();

    return View();
}

在这种情况下，我们手动生成一个线程。在这种情况下，Index 操作主体的执行可能需要稍长的时间（因为产生一个新线程比从现有池中提取一个线程更昂贵）。但是高级日志记录操作的执行将在不属于池的线程上完成。因此，我们不会危及池中的线程，这些线程仍然可以为其他请求提供服务。

---

是的 - 所有线程都来自线程池。您的 MVC 应用程序已经是多线程的，当请求进入时，将从池中取出一个新线程并用于为请求提供服务。该线程将被“锁定”（来自其他请求），直到请求得到完全服务并完成。如果池中没有可用的线程，则请求将不得不等到有可用的线程。

如果您有异步控制器，它们仍然从池中获取一个线程，但是在为请求提供服务时，它们可以放弃线程，同时等待某些事情发生（并且可以将该线程提供给另一个请求）以及原始请求需要线程时它再次从池中得到一个。

不同之处在于，如果您有很多长时间运行的请求（线程正在等待某物的响应），您可能会用完池中的线程来为基本请求提供服务。如果你有异步控制器，你就没有更多的线程了，但是那些正在等待的线程会返回到池中并且可以为其他请求提供服务。

一个近乎真实的例子......想象一下，就像上公共汽车，有五个人在等上车，第一个上车，付款并坐下（司机满足了他们的要求），你上车（司机正在服务您的请求）但您找不到您的钱；当您在口袋里摸索时，司机放弃了您并让接下来的两个人上车（满足他们的要求），当您找到您的钱时，司机再次开始与您打交道（完成您的请求）-第五个人必须等到你已经完成了，但第三和第四个人得到了服务，而你已经完成了一半的服务。这意味着驱动程序是池中唯一的线程，乘客是请求。如果有两个驱动程序，写它会如何工作太复杂了，但你可以想象......

如果没有异步控制器，您身后的乘客将不得不等待很长时间才能找到您的钱，同时公交车司机将无所事事。

所以结论是，如果很多人不知道他们的钱在哪里（即需要很长时间来响应驱动程序提出的问题），异步控制器可以很好地帮助处理请求，从而加快处理过程。如果没有 aysnc 控制器，每个人都会等到前面的人被完全处理掉。但是不要忘记，在 MVC 中，您在单个总线上有很多总线驱动程序，因此异步不是自动选择。

---

这里有两个概念在起作用。首先，我们可以让我们的代码并行运行以更快地执行，或者将代码安排在另一个线程上以避免让用户等待。你的例子

public ViewResult Index() { 

    Task.Factory.StartNew(() => { 
        //Do an advanced looging here which takes a while
    });

    return View();
}

属于第二类。用户将获得更快的响应，但服务器上的总工作量更高，因为它必须做同样的工作 + 处理线程。

另一个例子是：

public ViewResult Index() { 

    Task.Factory.StartNew(() => { 
        //Make async web request to twitter with WebClient.DownloadString()
    });

    Task.Factory.StartNew(() => { 
        //Make async web request to facebook with WebClient.DownloadString()
    });


    //wait for both to be ready and merge the results

    return View();
}

因为请求是并行运行的，所以用户不必等待，只要它们是串行完成的。但是你应该意识到，我们在这里比串行运行消耗更多的资源，因为我们在许多线程上运行代码，同时我们也有线程等待。

这在客户端场景中非常好。将同步长时间运行的代码包装在一个新任务中（在另一个线程上运行）也很常见，也可以保持 ui 响应或并行化以使其更快。尽管如此，一个线程仍然在整个持续时间内使用。在高负载的服务器上，这可能会适得其反，因为您实际上使用了更多资源。这是人们警告过你的

MVC 中的异步控制器还有另一个目标。这里的重点是避免让线程无所事事（这会损害可伸缩性）。仅当您调用的 API 具有异步方法时才重要。像 WebClient.DowloadStringAsync()。

关键是你可以让你的线程被返回来处理新的请求，直到网络请求完成，它会调用你的回调，得到相同的或新的线程并完成请求。

我希望您了解异步和并行之间的区别。将并行代码视为您的线程所在的代码并等待结果。虽然异步代码是在代码完成时通知您并且您可以重新开始工作的代码，同时线程可以执行其他工作。

---

如果操作异步运行，应用程序可以更好地扩展，但前提是有资源可用于为其他操作提供服务。

异步操作确保您永远不会因为现有操作正在进行而阻止操作。 ASP.NET 具有允许并行执行多个请求的异步模型。可以将请求排队并处理它们 FIFO，但是当您有数百个请求排队并且每个请求需要 100 毫秒来处理时，这将无法很好地扩展。

如果您有大量流量，最好不要异步执行查询，因为可能没有额外的资源来服务请求。如果没有备用资源，您的请求将被迫排队，花费指数级更长或彻底失败，在这种情况下，异步开销（互斥锁和上下文切换操作）不会给您任何帮助。

就 ASP.NET 而言，您别无选择 - 它使用异步模型，因为这对服务器-客户端模型有意义。如果您要在内部编写自己的代码并使用异步模式尝试更好地扩展，除非您尝试管理在所有请求之间共享的资源，否则您实际上不会看到任何改进，因为它们已经被包装在不阻塞其他任何东西的异步过程中。

最终，在您真正查看导致系统瓶颈的原因之前，这一切都是主观的。有时很明显，异步模式会在哪些方面有所帮助（通过防止排队的资源阻塞）。最终，只有测量和分析系统才能表明您可以在哪里获得效率。

编辑：

在您的示例中，Task.Factory.StartNew 调用将使 .NET 线程池上的操作排队。线程池线程的本质是可以重复使用（以避免创建/销毁大量线程的成本）。操作完成后，线程将被释放回池以供另一个请求重新使用（垃圾收集器实际上不会参与，除非您在操作中创建了一些对象，在这种情况下，它们会按正常方式收集范围界定）。

就 ASP.NET 而言，这里没有什么特别的操作。 ASP.NET 请求在不考虑异步任务的情况下完成。唯一的问题可能是您的线程池是否已饱和（即，现在没有线程可用于为请求提供服务，并且池的设置不允许创建更多线程），在这种情况下，请求被阻止等待启动任务，直到池线程变得可用。

---

是的，他们使用线程池中的线程。实际上，MSDN 提供了一个非常出色的指南，可以解决您的所有问题等等。我发现它在过去非常有用。一探究竟！

http://msdn.microsoft.com/en-us/library/ee728598.aspx

同时，您听到的关于异步代码的评论和建议应该持保留态度。对于初学者来说，仅仅做一些异步的东西并不一定会让它扩展得更好，而且在某些情况下会使你的应用程序扩展得更糟。您发布的关于“大量流量......”的其他评论也仅在某些情况下是正确的。这实际上取决于您的操作在做什么，以及它们如何与系统的其他部分交互。

简而言之，很多人对异步有很多看法，但断章取义可能并不正确。我会说专注于您的确切问题，并进行基本的性能测试以查看异步控制器等实际处理您的应用程序。

---

首先它不是 MVC，而是维护线程池的 IIS。因此，来自 MVC 或 ASP.NET 应用程序的任何请求都由线程池中维护的线程提供服务。只有使应用程序异步，他才会在不同的线程中调用此操作并立即释放线程，以便可以接受其他请求。

我已经用详细视频（http://www.youtube.com/watch?v=wvg13n5V0V0/“MVC 异步控制器和线程饥饿”）解释了相同的内容，它显示了 MVC 中的线程饥饿是如何发生的，以及如何通过使用 MVC 异步控制器将其最小化。我还使用 perfmon 测量了请求队列所以您可以看到 MVC 异步的请求队列如何减少，以及同步操作的最差情况如何。

---