限制并发线程等于处理器数量?

大多数线程不受CPU限制,它们最终会等待IO或其他事件。如果现在查看您的系统,我想您有100(如果不是1000)个线程在执行时没有问题。通过这种方法,您最好离开.NET线程池来做正确的事情!

但是,如果线程都是CPU绑定的(例如,类似于光线跟踪),那么最好将线程数限制为核心数,否则很可能上下文切换会开始影响性能。

线程池在这方面已经做得相当好了。它试图将正在运行的线程数限制为计算机中的CPU核心数。当一个线程结束时,它会立即调度另一个符合条件的线程来执行。

每0.5秒,它评估正在运行的线程的情况。当线程运行时间过长时,它假定它们已停止,并允许另一个线程开始执行。现在运行的线程比CPU核心的多。这可以达到threadpool.setmaxthreads()设置的最大允许线程数。

从.NET 2.0 SP1开始,默认的最大线程数大大增加到核心数的250倍。你永远不应该去那里。如果这样做,您将浪费大约2分钟的时间来运行可能不是最佳数量的线程。但是,这些线程都必须阻塞这么长时间,而不是线程的典型执行模式。另一方面,如果这些线程都在等待同一种资源,它们可能只是轮流等待,那么添加更多的线程就不能提高吞吐量。

长话短说,如果运行的线程执行速度很快(最多几秒),并且长时间不阻塞,那么线程池将工作良好。当代码与该模式不匹配时,您可能应该考虑创建自己的线程对象。

好吧,如果您的瓶颈仅仅是处理器,那么它可能是有意义的,但是这会忽略所有内存和其他I/O瓶颈,并且可能至少您的缓存内存正在抛出页面错误和其他会减慢线程速度的事件。

我相信图书馆自己。线程等待各种各样的事情,你不希望你的应用程序慢下来,因为它不能产生一个新的线程,即使大多数其他线程只是在睡觉,等待一些事件或资源。

在各种线程:处理器比率下测量应用程序。根据应用程序的硬数据得出结论。不接受第一原则中关于你的表现的论点 应该 得到,只有你自己 做 解决问题。