ASP.NET MVCmultithreading，值得吗？
我有点困惑，我的ASP.NET MVC应用程序将托管在服务器上，所以有什么意义使它成为multithreading的？ 例如，如果我想要一个线程来执行我的翻译，这是个好主意吗？ 有人可以向我详细说明吗？ 我对网络应用程序multithreading与桌面应用程序multithreading有点混淆。
有一些事情要做。
首先，每个ASP.NET应用程序（MVC或其他）本质上都是multithreading的：每个请求都将在一个单独的线程上处理，因此您将自动处于multithreading情况，并且必须考虑对任何数据的共享访问（例如静力学等）。
另一个是使用MVC，它特别容易编写异步控制器方法，如：
public async Task Index(int id) { var model = await SomeMethodThatGetsModelAsync(id); return View(model); } 现在，如果我们已经是multithreading的话那么为什么呢？ 使用更少线程的好处（具有讽刺意味的是）。 假设SomeMethodThatGetsModel(id)可能阻塞或以其他方式阻塞线程， await SomeMethodThatGetsModelAsync(id)允许当前线程处理另一个请求。 Web服务器可以处理多少请求的限制之一是它可以处理这些请求的线程数。 释放线程，增加吞吐量。
另外，您可能希望在应用程序的后台进行一些操作，这里的原因与桌面应用程序相同。
简单地说，如果你有可以同时完成的工作和阻塞（例如，点击数据库和两个web服务），那么你以multithreading方式这样做的原因与桌面应用程序相同。
（在最后两种情况下，要小心使用默认的静态线程池，例如通过ThreadPool.QueueUserWorkItem或Task.Run 。因为如果你大量使用它，那么相同的线程池用于主ASP.NET线程’一些这样的用法绝对没问题，但是如果你大量使用单独的线程，那么可以使用一组单独的线程，也许使用你自己的池化机制。
有没有必要让它成为multithreading？
那是行不通的。 问题是：您的应用程序是否需要multithreading？ 例如，如果您收到大型实体的集合，需要在进一步操作之前以某种方式对其进行预处理，您可以在单独的线程中处理它们而不是循环。
我对网络应用程序multithreading与桌面应用程序multithreading有点混淆
asp.net和桌面中的multithreading是一样的，并且工作方式相同。