TaskFactory 错过正在运行的任务答案

【问题标题】：TaskFactory miss running tasksTaskFactory 错过正在运行的任务
【发布时间】：2012-07-12 11:11:33
【问题描述】：

如果已经有太多任务排队，TaskFactory 是否有可能长时间不运行任务？如果是这样，有一种方法可以配置 taskfactory，以便它能够更快地运行更多任务。

另外，在同一个进程中同时使用 TaskFactory 和 Threadpool.QueueUserWorkItem 会有什么问题吗？我们有一些仍然使用 Threadpool 类的旧库。

【问题讨论】：

【解决方案1】：

阿尔文。当您将要运行的任务排队时，它们将被安排使用 ThreadPool 中的线程运行。运行多少任务，以及它们运行的速度将取决于可用线程的数量以及特定任务执行所需的时间。如果有很多队列任务，线程池能够根据需要启动新线程，但这在很大程度上取决于可用资源和 cpu。可以将线程池配置为设置默认线程数，但在大多数情况下不建议这样做。

同时使用任务和 Thrapool.QueueUserWorkItem 应该没有任何问题，因为默认任务调度程序使用相同的线程池。所有这一切都会发生，您将有更多排队的任务等待同一个线程池处理。

【讨论】：

我遇到了一些任务延迟 2 分钟的问题。我认为这可能是因为应用程序正在安排太多任务。有没有办法查出 taskfactory 是否有太多的任务入队？

【解决方案2】：

使用TPL，你的任务会自动进入线程池；线程池在其中密切关注它将同时运行的正在运行的线程数。过多的活动线程会降低性能并增加操作系统的管理负担。一旦达到线程数量的预定义限制，它们就会被排队。一些背景...

线程池从池中的一个线程开始，池管理器“注入”新线程以应对额外的异步工作负载，达到某个限制最大值。在一段时间的不活动之后，如果池管理器“认为”这样做会带来更好的吞吐量，它可能会“退休”线程。在您上面的情况下，池管理器正在限制并发线程的数量。

您可以通过调用Thread.Pool.SetMaxThread;来设置池将创建的线程数上限，默认为：

1023 in Framework 4.0 in a 32-bit environment.
32768 in Framework 4.0 in a 64-bit environment.
250 per core in Framework 3.5.
25 per core in Framework 2.0.

[这些数字可能因硬件和操作系统而异]。

数量如此庞大（至少在 .NET 4.0 的情况下）的原因是为了确保即使在某些线程被阻塞（运行一些紧张的工作等）时也能取得进展

您可以通过ThreadPool.SetMinThreads 设置下限。这个限制器的作用比最大限制器的作用更微妙：它指示池管理器不要延迟线程的创建，直到达到这个数量的下限——设置这个数量将提高你在有阻塞线程时的并发性。

如果您使用的是早于 Framework 4.0 的版本，则无法使用 TPL。您可以使用 4.0 并致电 QueueUserWorkItem - 这（乍一看）不会给您带来任何问题。

我希望这会有所帮助。

【讨论】：

虽然 TPL 仅作为 .net 4.0 的一部分提供，但有/曾经有一个可与 .net 3.5 一起使用的独立库，如果您在网络上搜索仍然可以找到它。在我们更新到 .net 4.0 之前，我经常使用这个库。
酷，我不知道这个......干杯。
您仍然可以从 pfx 团队博客中获得它。我认为没有官方的 Microsoft 下载站点了。
我遇到了一些任务延迟 2 分钟的问题。我认为这可能是因为应用程序正在安排太多任务。有没有办法查出 taskfactory 是否有太多的任务入队？
Goto VS2010 Debug > Windows > Threads 这将为您提供“线程堆栈”，并且应该使您能够找出有多少并发线程...