C# 跟踪.NET/IIS程序中的线程使用情况

我们有多线程的软件。一个源线程启动一系列并行任务（每个任务都涉及一些处理，一些与第三方API对话），并等待部分或全部任务完成

每个线程需要3-30秒来完成其工作

我们发现（在prod中）调用

ThreadPool.QueueUserWorkItem

和线程实际启动之间可能会有长达10秒的延迟，因此我们认为线程池中可用的线程供应已经饱和。 有关该限额的评论，请参见此处：

我们希望能够跟踪这些不同数量的线程，这样一旦我们进行了各种更改，我们就有了一些东西，我们可以指出并说“看，我们已经解决了所有线程的问题”

这个MSDN页面：意味着没有计数器来跟踪这类事情，只提供DIY计数器的建议实现

另一方面，此页面：表示计数器确实存在？似乎说“最大线程数”、“总线程数”和“活动线程数”应该是相关的。我认为这意味着：

• “最大”：TP可以创建多少线程，然后才能开始等待旧线程死亡，然后才能创建新线程
• “活动”：在任何给定时间，实际运行程序代码的线程数
• “总计”：？？我猜这是“活动”+“已启动但正在等待外部资源的线程数”？在我们的例子中是第三方API，但通常可能是磁盘IOs或DB访问等

我试图通过打开性能监视器“添加新计数器”>“W3SVC\U W3WP”>选择这3个特定计数器>选择我们的特定进程>“添加”>“确定”来查看这些计数器

然后，性能监视器图告诉我们： 最大值=256 总数=16 活动=0

那似乎。。。不大可能发生的我假设我要么误解了计数器，要么错误配置了性能监视器

我们的下一个尝试是查看任务管理器中进程的“线程”列（通过IIS管理器中的PID识别正确的w3wp进程）。这通常显示有100-150个线程，但如果我真的对进程进行了研究（对它正在运行的API端点进行垃圾邮件处理），那么我可以将这个数字提高到256（我在一个点上看到它是264）

有人能解释一下吗

---

基本上，我的问题是，在

线程池.QueueUserWorkItem

的上下文中，所有这些不同的数字/统计数据具体意味着什么？跟踪线程池的线程可用性状态的最佳方法是什么。

您是否考虑过创建自己的线程而不是使用线程池？通过这种方式，您可以创建所需的任意多个线程（除非您达到了系统的极限，在今天的计算机上，这将是非常高的，几千个），并跟踪它。对于某些特殊情况，我有自己的foregrund线程池，与默认线程池相比，自定义实现速度更快，功能更广泛。