我已经对服务器应用程序中多线程的动态和含义（使 clr 线程池饥饿等）进行了大量阅读，但为了论证起见，假设我正好需要完成 4 个异步进程，我需要根据我的 （asp.net） 页面的请求完成...... 现在，假设时间是更关键的因素，我的网站不应该遇到大量流量。 在这种情况下，使用 new Thread() 方法生成 4 个线程还是ThreadPool.QueueUserWorkItem method更可取？
在这里担心（和我的观点）是使用 ThreadPool method ，它可能会创建一个比我真正想要的太大的线程池？当我只需要 4 个线程时，我不能自己生成它们以保持分配的应用程序域、clr 线程的数量最少吗？
生成线程是一项成本非常高的操作，因此延迟很高。如果要自己管理线程（这是合理的，但不是必需的），则必须构建自定义池。
使用线程池工作项并非没有危险，因为它不能保证并发级别为 4。如果您碰巧得到 2 或 3，那么您的 HTTP 请求将有更多的延迟。
我会使用线程池并使用SetMinThreads来确保线程立即启动并且始终有足够的线程。
我肯定会选择ThreadPool的方法。它正是为这种场景而设计的。线程池将在内部管理所需的线程数，确保不会使系统过载。引用自MSDN：
线程池提供新的工作线程或 I/O 完成线程 按需，直到达到每个类别的最小值。当一个 达到最小值，线程池可以在 该类别或等到某些任务完成。从 .NET Framework 4，线程池创建和销毁工作线程 为了优化吞吐量，其定义为 按单位时间完成的任务。线程太少可能无法生成 优化使用可用资源，而线程过多可能会 增加资源争用。
如果你真的很偏执，你可以用SetMaxThreads手动限制它。进行手动线程管理只会引入潜在的错误。
如果您可以访问.net 4.0，则可以使用TPL Task类（它也使用引擎盖下的ThreadPool），因为它具有更具吸引力的功能。