任务vs线程池

请查看ParallelOptions。MaxDegreeOfParallelism for Task s.

我建议你使用任务，因为它们提供了比ThreadPool更高层次的抽象。

在这里可以找到一个关于这个话题的很好的读物。真的，一本必须拥有的书，而且它是免费的:)

在TPL中，可以在ParallelEnumerable或ParallelOptions.MaxDegreeOfParallism上使用WithDegreeOfParallelism

还有CountdownEvent，如果你只是使用自定义线程或任务，这可能是更好的选择。

在ThreadPool中，当你使用SetMaxThreads时，AppDomain是全局的，所以你可能会不必要地限制不相关的代码。

不能将工作线程数或I/O完成线程数设置为小于计算机中的处理器数的数。

如果公共语言运行时托管，例如由Internet Information Services (IIS)或SQL Server托管，则主机可以限制或阻止对线程池大小的更改。

在更改线程池中的最大线程数时要小心。虽然您的代码可能会受益，但这些更改可能会对您使用的代码库产生不利影响。

将线程池大小设置得太大可能会导致性能问题。如果同时执行的线程太多，任务切换开销将成为一个重要因素。

我同意另一个答案，你应该使用TPL而不是ThreadPool，因为它是一个更好的多线程抽象，但它有可能在两者中完成你想要的。

任务对我来说有一个非常迷人的功能，可以构建任务链。它们是在任务之前的某些结果上执行的。我经常使用的功能如下:任务A在后台运行，以完成一些长时间运行的工作。我在它之后链接任务B，只有在任务A完成时才执行，我配置它在前台运行，所以我可以很容易地更新我的控件与长时间运行任务A的结果。

您还可以创建一个信号量来控制一次可以执行多少个线程。您可以创建一个新的信号量，并在构造函数中指定一次可以同时使用该信号量的线程数量。由于我不知道您将如何使用线程，因此这将是一个很好的起点。

MSDN关于信号量类的文章