CLR线程池的作用与原理浅析

CLR线程池的作用与原理浅析2011-07-17线程池是一个重要的概念。不过我发现，关于这个话题的讨论似乎还缺少了点什么。作为资料的补充，以及今后文章所需要的引用，我在这里再完整而又简单地谈一下有关线程池，还有.NET中各种线程池的基础。更详细的内容就不多作展开了，有机会我们再详细讨论这方面的细节。这次，还是一个“概述”性质的，希望可以说明白这方面问题的一些概念。

线程池的作用

其实“线程池”就是用来存放“线程”的对象池。

在程序中，如果某个创建某种对象所需要的代价太高，同时这个对象又可以反复使用，那么我们往往就会准备一个容器，用来保存一批这样的对象。于是乎，我们想要用这种对象时，就不需要每次去创建一个，而直接从容器中取出一个现成的对象就可以了。由于节省了创建对象的开销，程序性能自然就上升了。这个容器就是“池”。很容易理解的是，因为有了对象池，因此在用完对象之后必须有一个“归还”的动作，这样便可以把对象放回池中，下次需要的时候就可以再次拿出来使用了。

例如，我们在使用ADO.NET连接SQL Server时，.NET框架就会自动帮我们维护一个连接池，这就是因为重新创建一个连接的代价相对比较高昂，“复用”就显得比较划算了。不过有些朋友可能会说，我们明明是每次都创建一个SqlConnection对象，哪里有“复用”啊？这是因为.NET框架中把“连接池”做透明了，对于程序员完全隐藏了这个概念。每次我们虽然创建的是新的SqlConnection对象，但是这个对象内部占用的“数据库连接”还是会复用的。为什么总是强调用完SqlConnection对象后要及时“关闭”（Dispose或Close）呢？其实这里并没有断开数据库连接，只是把这个连接放回了连接池。等到下次创建新的SqlConnection对象时，这个连接又可以拿出来用了。

既然我们每次都是从池中获取对象，那么这些对象是由谁来创建，又是什么时候创建的呢？这个就要根据不同情况由各对象池来自行实现了。例如，可以在创建对象池的时候指定池内对象数量，并且一下子全部创建好，当然您也可以在得到请求时，如果发现池中已经没有剩余对象时创建。您也可以“事前”先准备一部分，“事中”根据需要再继续补充。还可以做得“智能”一些，例如，根据实际情况添加或删除一些对象，甚至对需求“走势”进行“预测”，在空闲时便创建更多的对象以备“不时之需”。各中变化难以言尽。

当然，它们的原理和目的是类似的。相信上面这段文字也已经讲清了“线程池”的作用：因为创建一个线程的代价较高，因此我们使用线程池设法复用线程。就是这么简单。

CLR线程池的作用

在.NET中，CLR线程和操作系统线程对应，您可以简单地认为.NET中的Thread对象便封装了一个操作系统线程，并附带一些托管环境下所需要的数据（如GC Handle）1。而CLR线程池便是存放这些CLR线程的对象池。

我们在编写程序的时候，可以使用ThreadPool类的两个静态方法：QueueUserWorkItem和UnsafeUserQueueWorkItem向CLR线程池中添加任务（一个WorkCallback委托对象），这两个方法的区别，在于前者会收集调用方的ExecutionContext，也就是保留了的当前线程的执行信息（如认证或语言文化等），使任务最终会在“创建”时刻的环境中执行2——后者就不会。因此，如果比较两个方法的绝对性能，Unsafe方法会略胜一筹。但是平时还是建议使用QueueUserWorkItem方法，因为保留执行上下文会避免很多麻烦事情，且这点性能损耗其实算不上什么。

CLR线程池在.NET框架中的作用很大，除了让程序员使用之外，其他一些功能也会依赖CLR线程池。如ThreadPool.RegisterWaitForSingleObject方法，或是System.Threading.Timer组件——还有更重要可能也是更隐藏的：ASP.NET在得到一个请求后，也会将这个请求处理的任务交由CLR线程池去执行——请注意，它们最多只是添加任务而已，并不表示任务会立即执行。所有添加到CLR线程池的任务都会在合适的时候得以执行——可能马上，也可能要稍等片刻，甚至更久。

向CLR线程池添加任务时，任务会被临时放到一个队列中，并在合适的时候执行。那么怎么样才算是“合适的时候”？简单的概括说来，便是线程池内有空闲的线程，或线程池所管理的线程数量还没有达到上限的时候。如果有空闲的线程，线程池就会立即让它领取一个任务执行。如果是第二种情况，线程池便会创建新的Thread对象。由于让操作系统管理太多线程反而会造成性能下降，因此CLR线程池会有一个上限。不同的托管环境会设置不同的上限。如在.NET 2.0 SP1之后，普通的Windows应用程序（如控制台或WinForm/WPF），会将其设置为“处理器数 * 250”。也就是说，如果您的机器为2个2核CPU，那么CLR线程池的容量默认上限便是1000，也就是说，它最多可以管理1000个线程同时运行——很多情况下这已经是一个很可怕的数字了，如果您觉得这还不够，那么就应该考虑一下您的实现方式是否可以改进了。