我可以同时运行多少个线程？

Question

对我的另一个问题的评论说,我只能连续地运行"这么多"线程,这是我在其他地方看到过的一个概念.

作为线程新手,我如何确定要使用的最大线程数？或者这是一个"字符串有多长"的问题？它取决于什么？硬件配置还是什么？

(在Visual Studio中使用.Net 3.5的VB,如果重要的话)

---

更新:是否有人知道任何可以建议多个线程(或任务)的s/w工具,或者我应该只编写自己的代码来继续尝试不同的数字,直到吞吐量下降？

---

[Upperdate]差不多七年之后我们现在有一个软件推荐网站,所以我问是否有一个工具来帮助解决这个问题.

Answer 1

这取决于硬件,因为您(可能)不使用理论计算机而是使用物理硬件计算机,因此您的资源有限.

阅读:Windows是否每个进程限制2000个线程？

此外,即使您可以运行5000多个线程,具体取决于您的硬件,也可能比10线程等效程序运行得慢得多.我想你应该看一下线程池.

Answer 2

通常,同时运行的线程数由您拥有的CPU和CPU核心(包括超线程)数决定.也就是说,在任何给定时间,(在操作系统中)运行的线程数等于"核"的数量.

您可以在应用中同时运行多少个线程取决于很多因素.最好的(非专业人员)号码将是机器上的核心数量,但当然这就像假装没有人(没有其他应用程序)其他存在:).

坦率地说,我会说在.NET/Windows中进行更多关于多线程的研究,因为当一个人没有真正扎实的理解时,他们往往会做更多的"伤害"..NET具有线程池的概念,除了Windows之外,您还需要知道它是如何工作的.

在.NET 3.5/4.0中,您应该查看任务(任务并行库),因为库可以更好地确定要生成多少个线程(如果有的话).使用TPL,线程池进行了重大改进,并且在生成线程和任务窃取等方面更加智能.但是您通常使用Tasks而不是线程.

这是一个复杂的领域,因此,.NET框架引入了任务,以便从线程中抽象程序员,从而允许运行时对此有所了解,而程序员只是说出她想要的东西,而不是如何做到这一点.

Answer 3

运行密集型任务时，一个很好的经验法则是运行与物理核心数相同的数量。

是的，您可以运行更多任务，但它们将等待资源（或线程池中的线程）和您的盒子，无论大小如何，都无法在 100% 的时间内将所有 CPU 核心资源分配给线程，原因是后台/其他进程。因此，您实例化的任务越多，您产生的线程就越多，因为它们超过了实际可能的并发线程（每个内核 1 个），就会发生更多的资源管理、排队和交换。

我们在我现在工作的地方进行的一项测试使用病毒模式来启动其他任务，发现最优值非常接近 cpu 计数作为上限。以一比一的比率启动的任务与物理核心数运行每个任务大约需要 1 分钟才能完成。设置为 cpu 计数的两倍，任务时间从平均 1 分钟增加到平均约 5 分钟完成。超过核心数启动的任务越多，它的速度就会越慢。

因此，例如，如果您有 8 个物理内核，那么 8 个任务（并且使用 TPL，本质上是活动进程中的 8 个并发线程）应该是最快的。您的主线程或进程会创建其他任务和其他后台进程，但是如果为了您的资源开发乐趣，该框非常孤立，那么这些将相当少。

当您从队列或列表中咀嚼任务时，根据核心数对任务上限进行编程的好处是，当您将应用程序部署在不同大小的盒子上时，它会自动调整自身。

为了以编程方式确定这一点，我们使用

var CoreCount = System.Environment.ProcessorCount / 2;

你问为什么要除以二？因为几乎所有现代处理器都使用逻辑内核或超线程。您应该通过自己的测试发现，如果您使用逻辑计数，则每个任务的整体速度以及整个过程将显着下降。物理内核是关键。我们看不到找到物理与逻辑的快速方法，但对我们的盒子的快速调查发现这始终是正确的。YMMV，但这可能会让你很快。

Answer 4

每个线程消耗更多内存(内核堆栈,线程环境块,线程本地,堆栈....).AFAIK在Windows中没有明确的限制,因此约束将是内存(可能是每个线程的堆栈).

在Linux中,线程更像是进程(具有共享内存),并受到以下因素的限制:

cat /proc/sys/kernel/threads-max