题

使用新线程和使用线程池中的线程有什么区别？有哪些性能优势？为什么我应该考虑使用池中的线程而不是我显式创建的线程？我在这里特别考虑的是 .NET，但一般的例子就可以了。

有帮助吗？

解决方案

线程池将为频繁且相对较短的操作提供好处

  • 重用已创建的线程而不是创建新线程（一个昂贵的过程）

  • 当新工作项的请求激增时限制线程创建的速率（我相信这仅在 .NET 3.5 中）

    • 如果您将 100 个线程池任务排队，它只会使用已创建的线程数来服务这些请求（例如 10 个）。线程池将进行频繁的检查（我相信在 3.5 SP1 中每 500 毫秒一次），如果有排队的任务，它将创建一个新线程。如果您的任务很快，那么新线程的数量将会很小，并且为短任务重用 10 个左右的线程将比预先创建 100 个线程更快。

    • 如果您的工作负载始终有大量线程池请求传入，那么线程池将根据您的工作负载进行调整，通过上述过程在池中创建更多线程，以便有更多线程可用于处理请求

    • 查看 这里 有关线程池如何在后台运行的更深入的信息

如果作业运行时间相对较长（可能大约一两秒，但这取决于具体情况），自己创建一个新线程会更合适

@Krzysztof - 线程池线程是后台线程，当主线程结束时将停止。手动创建的线程默认处于前台（主线程结束后将继续运行），但可以在调用 Start 之前将其设置为后台。

其他提示

.NET 托管线程池：-

  • 根据当前工作负载和可用硬件调整自身大小
  • 包含工作线程 和 完成端口线程（专门用于服务IO）
  • 针对大量相对短期的操作进行了优化

存在其他线程池实现可能更适合长时间运行的操作。

具体来说，使用线程池来防止您的应用程序创建 太多 线程。线程池最重要的功能是工作队列。也就是说，一旦您的计算机足够繁忙，线程池就会对请求进行排队，而不是立即生成更多线程。

因此，如果您要创建少量有限数量的线程，请自行创建。如果您无法预先确定可能创建多少个线程（例如它们是为了响应传入 IO 而创建的），并且它们的工作将是短暂的，请使用线程池。如果您不知道有多少，但他们的工作将长期运行，那么平台中没有任何东西可以帮助您 - 但您也许能够找到合适的替代线程池实现。

也

  

new Thread（）。Start（）

生成Foreground线程，如果关闭程序，它将不会死亡。 ThreadPool线程是在关闭应用程序时死亡的后台线程。

我对这些的相对资源使用感到好奇，并在我的2012双核英特尔i5笔记本电脑上使用.net 4.0发布版本在Windows 8上运行基准测试。线程池平均花费0.035毫秒开始平均5.06ms。换句话说，对于大量短期线程，池中的线程开始快了大约300倍。至少在测试范围（100-2000）个线程中，每个线程的总时间似乎非常不变。

这是基准测试的代码：

    for (int i = 0; i < ThreadCount; i++) {
        Task.Run(() => { });
    }

    for (int i = 0; i < ThreadCount; i++) {
        var t = new Thread(() => { });
        t.Start();
    }

点击此处查看之前的帖子：

我什么时候不应该在.Net中使用ThreadPool？

总结一下，如果你需要产生许多短的线程，Threadpool是好的，而使用Threads可以让你获得更多的控制。

使用线程池线程本地存储不是一个好主意。它给线程一个“身份”;并非所有线程都相等。现在线程池特别有用，如果你只需要一堆相同的线程，准备好在没有创建开销的情况下完成你的工作。

如果你需要很多线程，你可能想要使用ThreadPool。它们重用线程，为您节省线程创建的开销。

如果你只需要一个线程来完成某些事情，那么Thread可能是最简单的。

对于theadpool线程的主要需求是处理预计几乎立即完成的短任务。硬件中断处理程序通常在堆栈上下文中运行，这不适用于非内核代码，但硬件中断处理程序可能会发现应尽快运行用户模式I / O完成回调。为了运行这样的事情而创建一个新线程将是一个巨大的过度杀伤力。有一些预先创建的线程可以调度以运行I / O完成回调或其他类似的东西效率更高。

此类线程的一个关键方面是，如果I / O完成方法总是基本上立即完成而且从不阻塞，并且当前运行此类方法的此类线程的数量至少等于处理器的数量，唯一的方法任何其他线程可以在上述方法之一完成之前运行，如果其他方法块之一或其执行时间超过正常线程时间片;如果线程池按预期使用，那么这些都不会经常发生。

如果一个方法不能在开始执行的100ms左右退出，那么该方法应该通过主线程池以外的其他方式执行。如果一个人有很多要执行的任务，这些任务是CPU密集型但不会阻塞，那么使用一个应用程序线程池（每个CPU核心一个）分配它们可能会有所帮助，它与“主”核心分开。线程池，因为在运行非阻塞的CPU密集型任务时，使用比核心更多的线程会适得其反。但是，如果某个方法需要花费一秒或更长的时间来执行，并且大部分时间都会被阻塞，那么该方法应该可以在专用线程中运行，并且几乎肯定不会在主线程池线程中运行。如果长时间运行的操作需要由I / O回调之类的东西触发，那么应该在回调之前为长时间运行的操作启动一个线程，并让它在回调脉冲的监视器上等待，否则让回调在回调退出时启动一个新线程来执行操作，有效地将自己的线程返回到线程池。

一般情况下（我从未使用过.NET），线程池将用于资源管理。它允许将约束配置到您的软件中。它也可能出于性能原因而完成，因为创建新线程可能成本很高。

可能还有系统特定的原因。在Java中（我不知道这是否适用于.NET），线程管理器可以在从池中提取每个线程时应用特定于线程的变量，并在返回时取消设置它们（通常的方式传递类似的东西）身份）。

示例约束： 我只有10个db连接，所以我只允许10个工作线程访问数据库。

这并不意味着您不应该创建自己的线程，但是在某些条件下使用池是有意义的。

如果您不知道或无法控制将创建多少线程，则使用池是个好主意。

使用线程来替换列表控件的positionchanged事件上的数据库中的某些字段时出现问题（避免使用freez）。我的用户花了5分钟从数据库中获取错误（与Access连接太多）因为他正在更快地更改列表位置......

我知道还有其他方法可以解决基本问题（包括不使用访问权限），但池化是一个良好的开端。

许可以下： CC-BY-SA 和 归因
不隶属于 StackOverflow
scroll top