ASP.NET MVC 多线程，值得吗？

我有点困惑，我的 ASP.NET MVC 应用程序将托管在服务器上，那么使其成为多线程有什么意义吗？例如，如果我想要一个线程来执行我的翻译，这是一个好主意吗？有人可以向我详细说明一下吗？我对网络应用程序多线程与桌面应用程序多线程有点困惑。

这有几件事。

首先，每个 ASP.NET 应用程序（MVC 或其他）本质上都是多线程的：每个请求都将在单独的线程上处理，因此您会自动处于多线程情况，并且必须在对数据的任何共享访问中考虑这一点（例如静力学等）。

另一个原因是，使用 MVC 可以特别轻松地编写异步控制器方法，例如：

public async Task<ActionResult> Index(int id)
{
  var model = await SomeMethodThatGetsModelAsync(id);
  return View(model);
}

现在，如果我们已经是多线程了，那为什么还要麻烦呢？好处是（讽刺的是）使用更少的线程。假如说SomeMethodThatGetsModel(id)可能会阻塞或以其他方式阻止线程，awaiting on SomeMethodThatGetsModelAsync(id)允许当前线程处理另一个请求。 Web 服务器可以处理的请求数量的限制之一是它可以处理这些请求的线程数量。释放线程并提高吞吐量。

进一步的是，您可能希望某些操作在整个应用程序的后台进行，这里的原因与桌面应用程序相同。

类似地，如果您有可以同时完成且会阻塞的工作（例如，访问数据库和两个 Web 服务），那么以多线程方式执行此操作的原因与桌面应用程序相同。

（但在最后两种情况下，请谨慎使用默认的静态线程池，例如通过ThreadPool.QueueUserWorkItem or Task.Run。因为这个相同的线程池用于主 ASP.NET 线程，如果您频繁使用它，那么您将与框架同吃同一个盘子。一些这样的用途绝对没问题，但如果您大量使用单独的线程，那么请为它们使用一组单独的线程，也许使用您自己的池机制）。