如果已经有太多任务排队，TaskFactory是否可能长时间不运行任务？如果是这样，有一种方法可以配置任务工厂，使其能够更快地运行更多任务。
此外，在同一进程中同时使用TaskFactory和Threadpool.QueueUserWorkItem会有任何问题吗？我们有一些旧的库仍然使用Threadpool类。
Alvin。当您对要运行的任务进行排队时，它们将被安排使用ThreadPool中的线程运行。运行的任务数量和运行速度将取决于可用线程的数量以及特定任务执行所需的时间。如果有很多队列任务，线程池能够根据需要启动新线程，但这在很大程度上取决于可用资源和cpu。线程池可以配置为设置默认线程数，但在大多数情况下不建议这样做。
将Tasks和threadpool.QueueUserWorkItem一起使用应该不会有任何问题，因为默认的Task调度程序使用相同的线程池。所发生的只是，您将有更多排队的任务等待同一线程池处理。
使用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——这（乍一看）不会给您带来任何问题。
我希望这能有所帮助。