如果已排队的任务太多，TaskFactory是否有可能长时间不运行任务？如果是这样，有一种方法可以配置taskfactory，以便它能够更快地运行更多任务。
此外，在同一进程中同时使用TaskFactory和Threadpool.QueueUserWorkItem会有任何问题吗？我们有一些旧的库仍然使用Threadpool类。
答案 0 :(得分：2)
阿尔文。将任务排队等待运行时，它们将被安排使用ThreadPool中的线程运行。运行多少任务，以及它们运行的速度将基于可用线程的数量以及特定任务执行所需的时间。如果有很多队列任务，线程池能够根据需要启动新线程，但这在很大程度上取决于可用资源和cpu。可以将线程池配置为设置默认线程数，但在大多数情况下不建议这样做。
使用Tasks和Threapool.QueueUserWorkItem一起应该没有任何问题，因为默认的任务调度程序使用相同的线程池。所有这一切都将导致您将有更多排队的任务等待同一个线程池进行处理。
答案 1 :(得分：0)
使用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 - 这（乍一看）不会给您带来任何问题。
我希望这会有所帮助。