我有点困惑，我的ASP.NET MVC应用程序将托管在服务器上，那么使其多线程有什么意义？例如，如果我想让一个线程执行我的翻译，这是个好主意吗？有人可以向我阐述吗？我与Web应用程序多线程与桌面应用程序多线程混淆。
有几件事。
首先是每个ASP.NET应用程序（MVC或其他）本质上是多线程：每个请求将在单独的线程上处理，因此您会自动处于多线程的情况访问数据（例如静态等）。
另一个是，使用MVC特别容易编写异步控制器方法，例如：
public async Task<ActionResult> Index(int id)
{
var model = await SomeMethodThatGetsModelAsync(id);
return View(model);
}
现在，如果我们已经多线程，那么为什么要打扰呢？具有讽刺意味的是，使用较少的线程（具有讽刺意味的是）。假设SomeMethodThatGetsModel(id)可能会阻止或以其他方式固定线程，则SomeMethodThatGetsModelAsync(id)上的await允许当前线程处理另一个请求。网络服务器可以处理多少个请求的限制之一是它可以处理多少个线程来处理这些请求。释放线程，然后增加吞吐量。
进一步是您可能希望在整个应用程序的背景中进行一些操作，此处的原因与桌面应用程序相同。
，如果您有可以同时完成的工作，并且哪些块（例如，击中数据库和两个WebServices），那么您以多线程方式进行操作的原因与桌面应用程序相同。
（在最后两种情况下，要警惕使用默认的静态线程池，例如通过ThreadPool.QueueUserWorkItem或Task.Run。因为同一线程池（如果您重测）将其用于主ASP.NET线程与框架相同的盘子进食。一些这样的用途绝对可以，但是如果您大量使用单独的线程，那么为它们使用一组单独的线程，也许使用您自己的合并机构）。
是否有一个要使其多线程的点？
那是行不通的。问题是：您的应用程序需要多线程吗？例如，如果您收到大型实体的集合，则需要以某种方式进行预处理，然后再进行进一步的操作，则可以在单独的线程中而不是周期中处理它们。
我与Web Apps多线程与桌面应用程序混淆了多线程
ASP.NET和桌面中的多线程是相同的，并且以相同的方式工作。