浅谈线程池(上):线程池的作用及CLR线程池
2009-07-22 09:01 by 老赵, 18137 visits线程池是一个重要的概念。不过我发现,关于这个话题的讨论似乎还缺少了点什么。作为资料的补充,以及今后文章所需要的引用,我在这里再完整而又简单地谈一下有关线程池,还有.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个线程同时运行——很多情况下这已经是一个很可怕的数字了,如果您觉得这还不够,那么就应该考虑一下您的实现方式是否可以改进了。
对于ASP.NET应用程序来说,CLR线程池容量代表了应用程序最多可以同时执行的请求数量。对于托管在IIS上的ASP.NET执行环境来说,这个值由全局配置决定。这个配置在machine.config文件中system.web/processModel节点中,为maxWorkerThreads属性,它决定了为单个处理器分配的线程数。如果这个值为40,且机器上拥有4个处理器(2 * 2CPU),那么这台机器目前的配置表示在同一时刻,ASP.NET可以同时处理160个请求。某些参考资料建议您将其修改为每处理器80-100个线程,这时您只要修改相应的属性值就可以了。
既然有最大值,也就相应有了最小值,它代表了CLR线程池“总是会保留”的最少线程数量。由于线程会占用资源,如在默认情况下,每个线程将获得1MB大小的栈空间3。所以如果在系统中保留太多空闲线程对资源也是一种浪费。因此,CLR线程池在使用大量线程处理完大量任务之后,也会逐步地释放线程,直至到达最小值。CLR线程池的最小线程数量确保了在任务数量较少的情况下,新来的任务可以立即执行,从而省去了创建新线程的时间。在普通应用程序中这个值为“处理器数 * 1”,而在ASP.NET应用程序中这个值配置在machine.config文件中system.web/processModel节点的minWorkerThreads属性中4。
在某些时候可能会遇到这样的情况:在一个瞬间忽然来大量任务,每个任务的执行时间说长不长说短不短,不过足以导致线程池快速分配数百个线程。如果这个峰值之后就一片平静,那么势必造成大量空闲的线程,这种开销对性能的损耗也非常明显。因此,CLR线程池限制了线程的创建速度不超过每秒2个。这样,即使在某个瞬时获得了大量的任务,CLR线程池也可以使用相对较少的线程来完成所有工作5。
但是,还有一种情况也值得考虑。例如,对于一个比较繁忙的Web应用程序来说,一打开便会涌入大量的连接。由于线程的创建速度有限,因此可以执行的请求数量也只能慢慢增加。对于这种您预料到会产生大量线程,而且忙碌状况会持续一段时间的情况,限制线程的创建速度反而会带来损伤效率。这时,您就可以手动设置CLR线程池的最小线程数量。如果此时CLR线程池中拥有的线程数量较少,那么系统就会立即创建一定数量的线程来达到这个最小值。设置和获取CLR线程池最小线程数量的接口为:
public static class ThreadPool { public static void GetMinThreads(out int workerThreads, out int completionPortThreads); public static bool SetMinThreads(int workerThreads, int completionPortThreads); }
这两个接口的作用和使用方式应该足够明显了(不理解的话可以查阅MSDN),其中workerThreads参数便是CLR线程池的最小线程数,而completionPortThreads涉及到我们下次要讨论IO线程池,在此就不多作展开了。除了设置和读取CLR最小线程数的方法之外,ThreadPool还包含这些接口:
public static class ThreadPool { public static void GetMaxThreads(out int workerThreads, out int completionPortThreads); public static bool SetMaxThreads(int workerThreads, int completionPortThreads); public static void GetAvailableThreads(out int workerThreads, out int completionPortThreads); }
值得注意的是,无论是设置还是获取到的这些数值,都与处理器数量没有任何关系了。也就是说,在一台2 * 2CPU的机器上运行一个普通的.NET应用程序时:
- 调用GetMaxThreads方法将获得1000,表示CLR线程池最大容量为1000(250 * 4),而不是250。
- 调用SetMinThreads并传入100,表示CLR线程池所拥有的最小线程数量为100,而不是400(100 * 4)。
对于CLR线程池的简单描述就暂时先到这里了。如果您还有什么疑问请提出,我会加以补充。
相关文章
- 浅谈线程池(上):线程池的作用及CLR线程池
- 浅谈线程池(中):独立线程池的作用及IO线程池
- 浅谈线程池(下):相关试验及注意事项
注1:严格说来,Thread对象和系统线程对应关系还有些细节上的考虑。例如,Thread对象只有当真正Start了之后,CLR才会创建一个操作系统线程与它绑定。
注2:ExecutionContext是个很重要且很有用的对象,例如,WinForms或WPF的异步任务中操作界面元素抛出异常该怎么办呢?
注3:使用Windows API或Thread类创建线程时可以指定它的栈空间大小,但是CLR线程池中的线程只能使用默认值——不过这个默认值也和托管环境有关,如普通应用程序默认为1MB,而ASP.NET为250KB,这意味着ASP.NET应用程序相对更容易产生Stack Overflow异常。
注4:可惜的是,对于processModel节点的数据,ASP.NET只会读取machine.config中的全局配置信息,这意味着我们不能使用web.config为不同应用程序配置不同的参数。如果我们要实现应用程序级别的配置,那么必须使用ThreadPool类中提供的API进行设置,这点稍后便会提到。
注5:对于这点,您不妨来做一个算术题:线程池内一下子涌入了500个任务,每个任务阻塞或暂停5秒,每个线程占用1MB内存,假设线程池目前为空,且有着足够的容量,此外线程创建速度也足够快,那么在限制及不限制线程创建速度的情况下,完成这些任务需要多少时间和内存空间?
真会占位置,下篇就给个连接。