C# IIS工作线程与web应用程序线程

我正在维护一个ASP.NET核心的web应用程序，它需要反复运行一些后台线程。我知道这不是一个好的设计，但目前我必须以最小的努力解决它的主要问题。现在我想知道我是否应该担心通过web服务器处理用户http请求

问题很简单，但我找不到任何明确的答案：

在应用程序中创建的线程之间有什么区别：

Task.Run(() => { // some parallel job })

和处理http请求的IIS工作线程？

它们是来自同一个线程池还是驻留在不同的线程池中？

根据“一个线程池”的说法：“ASP.NET Core已经在普通线程池线程上运行应用程序代码。”换句话说，服务请求的线程与后台线程之间没有单独的最大值

最大的区别是IIS知道它为传入请求创建的线程。IIS不知道您自己创建的任何线程

当回收应用程序池或关闭IIS时，它会等待所有请求完成处理—它会等待为每个请求创建的线程完成处理—然后终止该进程。如果您创建的线程比请求的生命周期长（例如，如果您创建了一个后台线程，然后将响应发送回客户端），IIS不知道该线程仍在运行，并且可能随时终止整个进程

如果在所有线程完成之前都不返回响应，那么就不会出现该特定问题

---

另一个问题是，可能会达到允许的最大线程数。然后各种奇怪的性能问题就会发生。但这取决于您创建的线程数量和HTTP请求数量。

Web服务器设计用于接收请求、处理请求并快速返回，不应用于“密集型”代码。在我看来，这些辅助任务应该在不同的（非web）服务器上运行，这样它们就不会干扰服务网页的工作。@Neil你完全正确，但问题的焦点更多地是两种线程之间的差异及其相互关系和影响。它们基本上是相同的。但您不应该在web服务器应用程序上这样做。每次这样做都会降低性能和可用性。@PauloMorgado我同意这不是一个好的设计，这个系统是多年前设计的，目前我必须以最小的努力解决它的问题。您能更详细地解释iis线程和应用程序线程的关系吗？如果它们是相同的，那么它们如何与托管应用程序域和非托管http请求上下文进行交互就让我感到困惑！通常，如果您在web服务器上使用

Task.Run

，这是因为您在处理web请求时做了一些不应该做的事情。如果你在上面阻塞了当前线程，那么你将无法获得双倍的成本。处理请求的线程、处理I/O回调的线程、运行异步continuations和

Task.run的线程都使用来自同一线程池的线程。如果浪费它们，会使整个应用程序变慢，甚至可能导致死锁。谢谢Gabriel的回答，所以你说这两种类型的线程都驻留在公共
线程池中，对吗？我们是否可以分别为IIS工作线程和应用程序后台线程设置最大数量限制，以防止它们相互爆炸？！您标记了ASP.NET核心。您使用的是核心还是普通的ASP.NET？这也可能取决于您是否正在运行核心应用程序，它是否在进程中。它是
ASP.NET Core
。目前，它的主机是进程中的
，
，但如果您也能解释进程外的
的区别，我将不胜感激，因为它是一个完整的池：“ASP.NET Core已经在普通线程池线程上运行应用程序代码了。”换句话说，服务请求的线程和后台线程没有单独的最大值。