这种做法可以让我们不用那么复杂的去实现创建，重用线程的逻辑，但是也有一些限制，比如由他内置的方法，我们不知道什么时候线程池里面的任务会结束，也不能获取线程的返回值。为了解决这些问题，微软引入了一个新的概念。

引入了Task之后，你可以用如下实现来替代ThreadPool

这些实现都是等价的。Task本身实现了很多ThreadPool不能做的事情。

?

更多Task同步编程的使用，请参见(还没写，先给自己挖个坑O(∩_∩)O)。

ThreadPool.QueueUserWorkItem没有提供一种简单的机制来获取线程的返回值。异步委托解决了这个问题，支持了传入一系列的参数。此外，异步委托中没有处理的异常会很方便的在调用线程的重新抛出（在调用EndInvoke的时候），因此不需要显示的处理。

通过异步委托来执行任务主要分一下几步：

调用BeginInvoke不会阻塞当前线程，因此你可以在调用完之后执行其他你想要同步的操作

?

EndInvoke主要做3件事： 1. 等待异步委托完成 2. 接收返回值 3. 把异步线程中未处理的异常在当前线程中重新抛出。

你也可以在调用BeginInvoke的时候指定一个回调方法，这个方法会在异步委托结束的时候自动调用。这样异步委托就像是一个后台线程一样自动执行，不需要主线程等待。只需要在BeginInvoke的时候做一些额外的操作即可实现这种操作。

Jeffery在C# via CLR Chapter27中针对线程池的使用给出了一些建议。目前我们允许开发者来指定一个线程池的最大线程数。但是事实证明，我们往往不应该为一个线程池指定线程的上限，否则可能会出现程序死锁或者饿死的状态。比如你可能设置了1000个线程，但是某一时刻正好有第1001个线程需要等待所有线程结束才能执行，这种情况如果你限制了线程池线程的个数，就会出现死锁。从开发的另一个角度说，你也不应该限制一个进程使用多少资源，比如一个进程可以使用多少内存，使用多少带宽.因此虽然目前你可以通过GetMaxThreads， SetMaxThreads，GetMinThreads，SetMinThreads ，GetAvailableThreads来进行线程个数的限制，但是他仍然不建议大家这样做。这些限制可能会让你的程序运行的更慢。

关于使用Task访问线程池：