147

使用新线程和使用线程池中的线程有什么区别？有哪些性能优势，为什么我应该考虑使用池中的线程而不是我明确创建的线程？我在这里专门考虑.NET，但一般示例很好。

4

11 回答 11

119

线程池将通过以下方式为频繁且相对较短的操作提供好处

  • 重用已经创建的线程而不是创建新的线程（一个昂贵的过程）
  • 当对新工作项的请求激增时限制线程创建速率（我相信这仅在 .NET 3.5 中）

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

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

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

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

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

于 2008-10-23T14:48:06.343 回答
16

.NET 托管线程池：-

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

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

具体来说，使用线程池来防止您的应用程序创建太多线程。线程池最重要的特性是工作队列。也就是说，一旦你的机器足够繁忙，线程池会将请求排队，而不是立即产生更多线程。

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

于 2008-10-23T14:56:59.570 回答
13

还

new Thread().Start()

如果关闭程序，生成不会死的前台线程。ThreadPool 线程是在您关闭应用程序时终止的后台线程。

于 2008-10-23T14:52:26.523 回答
10

我很好奇这些资源的相对使用情况，并在我的 2012 双核 Intel i5 笔记本电脑上使用 Windows 8 上的 .net 4.0 版本运行了基准测试。线程池平均需要 0.035 毫秒才能启动，而线程平均需要 5.06 毫秒小姐。换句话说，对于大量短期线程，池中的线程启动速度大约快 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();
    }

在此处输入图像描述

于 2016-02-01T06:56:09.230 回答
5

在此处查看较早的线程：

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

总结是，如果您需要生成许多短期线程，Threadpool 是很好的选择，而使用 Threads 可以为您提供更多控制。

于 2008-10-23T14:48:31.040 回答
3

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

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

于 2008-10-23T14:50:09.227 回答
2

线程本地存储对于线程池来说不是一个好主意。它赋予线程一个“身份”；不再是所有线程都是平等的。现在，如果您只需要一堆相同的线程，准备好在没有创建开销的情况下完成您的工作，线程池就特别有用。

于 2008-10-23T14:46:50.620 回答
2

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

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

如果一个方法不能在它开始执行的 100ms 左右内退出，则该方法应该通过主线程池以外的其他方式执行。如果有很多任务要执行，这些任务是 CPU 密集型但不会阻塞，使用与“主”线程池分开的应用程序线程池（每个 CPU 核心一个）调度它们可能会有所帮助，因为使用在运行非阻塞 CPU 密集型任务时，线程多于内核将适得其反。但是，如果一个方法需要一秒钟或更长时间才能执行，并且大部分时间都被阻塞，那么该方法应该可能在专用线程中运行，并且几乎可以肯定不应该在主线程池线程中运行。如果需要通过 I/O 回调等触发长时间运行的操作，

于 2015-02-21T21:25:34.993 回答
1

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

也可能有系统特定的原因。在 Java 中（同样我不知道这是否适用于 .NET），线程的管理器可能会在每个线程从池中拉出时应用线程特定的变量，并在返回时取消设置它们（传递类似一个身份）。

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

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

于 2008-10-23T14:54:29.310 回答
1

主题：

  1. 创建线程远比使用线程池慢。
  2. 您可以更改线程的优先级。
  3. 与资源相关的进程中的最大线程数。
  4. 线程处于操作系统级别，由操作系统控制。
  5. 当任务运行时间相对较长时，使用 Thread 是更好的选择

线程池：

  1. 在线程池上运行线程比直接创建线程要快得多。
  2. 您不能更改基于线程池运行的线程的优先级。
  3. 每个进程只有一个线程池。
  4. 线程池由 CLR 管理。
  5. 线程池对于短期操作很有用。
  6. 线程池中的线程数与应用程序负载有关。
  7. TPL 任务基于线程池运行
于 2020-02-01T13:19:13.970 回答
0

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

只是使用线程在positionchanged列表控件事件上更新数据库中的某些字段的表单存在问题（避免冻结）。我的用户花了 5 分钟从数据库中收到错误（与 Access 的连接太多），因为他更改列表位置的速度太快了......

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

于 2014-01-08T16:58:31.893 回答