写在前面：

ThreadPool到底应该怎么写，也许我一直打不开思路。多线程技术，不太好学习。更不容易理解，想要写好，就更不容易。我想这可能就是到目前为止国内关于多线程编程的书，少之又少的原因。这个系列的文章，我也是在不断的摸索中不断的前进，其中错误之处、抑或是理解不到位的地方，还希望大家帮忙指出，这样大家才能一起进步。

  上篇文章，大致介绍了为什么要使用ThreadPool,也许讲的比较简单，请大家谅解。ThreadPool最早出现在Windows 2000中。当时Microsoft® .NET Framework 小组在设计CLR时，就决定在CLR中实现线程池。这样就可以保证在任何托管的应用中都能使用线程池。那么在什么场合下才适合使用ThreadPool呢？

1、在什么时候适合使用ThreadPool?

在了解这个问题之前，我们先来看看.Net本身使用ThreadPool的一个例子。（.Net自身有很多使用ThreadPool的地方，大家可以抽空研究一下）

搞过ASP.NET的人都知道，ASP.NET是基于请求-响应模型的一种Web开发模型。当客户端发送一个请求，ASP.NET在得到一个请求后，也会将这个请求处理的任务交由CLR线程池去执行，如下图。

那么为什么要交给线程池来执行呢?先来看看Web程序自身的特点。

1、可能有多个客户端同时发送请求。

2、请求的次数可能非常频繁。

3、我们不需要对其进行精确的控制，也就是对请求什么时候开始、请求完成情况怎么样、以及请求什么时候结束，不需要精确的控制。

从上面的特点可以看出，使用线程池所带来的好处。针对多而频繁的请求，我们就无需在线程的创建上耗费太多的资源。

所以从上面的案例可以看出ThreadPool适合如下的场合

1、有大量独立较小的任务在后台运行。

2、不需要对用来执行任务的线程进行精细控制。

3、线程池主要用于减少因频繁创建和销毁线程带来开销，因此那些经常使用且执行时间短的线程才需要用线程池来管理，用ThreadPool即可。

总结：

        关于何时适合使用ThreadPool，受限于我的个人水平，可能我总结的不够全面，欢迎大家补充。到底该不该使用ThreadPool，需要综合考虑具体功能的特点，以及自己编写线程管理的复杂度来确定，没有一种方案是适用所有情况的。下篇文章，我将介绍如何使用ThreadPool。