我正在编辑一个多线程应用程序，所以我必须学习它并有一个理论问题。
拥有第二个线程允许应用程序在主线程等待资源变为可用时继续运行，因此如果正确完成，它应该加速应用程序。
我的想法是，在单个线程应用程序中只有浪费的处理时间，所以如果你有很多线程，那么每个线程都必须等待转向处理，从而导致一个较慢的程序。
我弄错了吗？
如果不是建议的经济线数。
答案 0 :(得分：1)
看看这里：
-----编辑-----
线程只是为了更好地利用你的CPU，所以它们不应该加速你的应用程序。
以前，在我的多线程应用程序中，我创建了自己的线程池，实际上是2-5核心。现在我使用系统API管理的池，最多可以达到30个。
我的建议是，在异步API的基础上构建您想要并行运行的任务，并花费一些时间来构建调用图。这样每个任务都可以给任何线程。这样做，让系统为您提供下一个可用的线程。
另一个建议是，在你的线程中减少调用API进入内核的时间。
在您的情况下，您必须找到瓶颈，磁盘，网络。
答案 1 :(得分：0)
我实际上认为你对并行计算背后的理论更感兴趣，而不是多线程：see here。
简短的回答是，它在很大程度上取决于工作实际上的并行化程度，处理它的处理器数量，以及并行化部分之间存在多少数据依赖性。
答案 2 :(得分：0)
这不是浪费。并且多线程并不总是正确的解决方案。
如果您有一个设计为顺序的单线程代码（每行代码都需要处理前一行代码），那么将它分成不同的线程是毫无意义的。
多线程只有在你可以打开线程而不是用连接冻结一个（当你不必真正等待其他线程完成时）时才会很好。
您需要考虑的另一件事是单个线程在单个处理器中运行。因此，如果您有一个很长的计算（如矩阵乘法），您可以将块分成多处理器计算机上的不同处理器。
那么，有多少？这取决于你在做什么。
如果你只是在做一个异步方法，你只想让它运行并在它完成时返回一个值，那么线程数没有限制。您可以使用逻辑上找到的数量（虽然有太多线程的开销）
如果要分解计算并将不同的块发送到不同的处理器，则没有理由打开更多的线程然后处理器的数量。 （虽然我发现在某些情况下，如果使用大约1.5的处理器数量，你可以获得更好的结果）