随着时间的推移，.NET 有什么充分的理由减少并行线程的数量吗？
我正在许多遍中运行计算，需要几天时间才能完成(每遍大约需要 1 小时)。这些任务是对内存中数据(从磁盘读取)的纯粹计算。我在几个地方使用了 Parallel.For 和 Parallel.ForEach ，无论是在主要任务还是在任务内部。一切都会在许多遍中重复。每次传递都会正确处理类实例(内存分析器显示随着时间的推移没有问题)，并创建一个新实例。它在每次传递中重复 100% 相同的任务，除了数学中的一些数字被更改(每次迭代次数相同，数据集相同)。
计算机有六个核心，应用程序启动时会使用所有核心。一段时间后，它使用 5 个，然后是 4 个，然后是 3 个，然后是 2 个。查看并行堆栈(调试 -> 窗口 -> 并行堆栈)，它确认只有那么多堆栈在运行。
.NET 为什么每次传递时都没有达到最大线程数？它是否根据 CPU 使用情况来调节线程？
关于如何调试的提示？我可以强制使用线程数吗？
最佳答案
我相信ThreadPool concurrency上的这篇文章应该会提供一些线索。
并行方法创建的任务最终将由线程池执行。 ThreadPool 使用的理想线程数根据正在执行的任务类型而变化。如果任务阻塞很多并且没有太多争用，则更多的线程数将导致更高的吞吐量。对于没有太多阻塞和对有限资源的高竞争的任务，较少的线程数将导致较高的吞吐量。
由于此属性，.NET 4 中的 ThreadPool 实现了一种“爬山”算法，它可以调整 ThreadPool 正在运行的线程数，并根据测量吞吐量使用react。
因此，您可以检查的一件事是查看实际作业吞吐量是否随着线程数量的减少而减少。也有可能，当您的应用程序运行时，它在磁盘操作上遇到越来越多的瓶颈，并且线程只是因为不使用而被关闭。
至于强制ThreadPool使用一定数量的线程，我认为这是不可能的。有ThreadPool.SetMinThreads但这对我来说从来没有用过。一般来说，.NET 将忽略这些值并使用它想要的任意数量的线程。
关于.NET 减少了重复运行时的并行线程，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/7027758/