线程池的介绍及简单实现--ibmdw
线程池尺寸任务数没有应用线程池所用的时间（单位:毫秒，OS:win）应用线程池所用的时间（单位:毫秒，OS:win）没有应用线程池所用的时间（单位:毫秒，OS:Solaris）应用线程池所用的时间（单位:毫秒，OS:Solaris）1500038961306513327250003455151622165945000342512054484338500034751605769147816500035052115785197032500034552516403875645000359550151821103128500035158815154405256500034953104550215895125000342554885667126216120022316220202113164201027101682020222416163020294816324020461081664602072199161281102014833516256201202521321651241140522382161024811711233610162048155280204513516409628742504828787
图1.线程池的尺寸的对服务器程序的性能影响
根据以上统计数据可得出下图：
图2.任务数对服务器程序的冲击?
数据分析如下：
图1是改变线程池尺寸对服务器性能的影响，在该测试过程中，服务器的要完成的任务数固定为为5000。从图1中可以看出合理配置线程池尺寸对于大量任务处理的效率有非常明显的提高，但是一旦尺寸选择不合理（过大或过小）就会严重降低影响服务器性能。理论上"过小"将出现任务不能及时处理的情况,但在图表中显示出某些小尺寸的线程池表现很好，这是因为测试驱动中有很多线程同步开销，且这个开销相对于完成单个任务的时间是不能忽略的。"过大"则会出现线程间同步开销太大的问题，而且在线程间切换很耗CPU时间，在图表显示的很清楚。可见任何一个好技术，如果滥用都会造成灾难性后果。
图2是用不同数量的任务来冲击服务器程序，在该测试过程中，服务器线程池尺寸固定为16。可以看出线程池在处理少量任务时的优势不明显。所以线程池技术有一定的适应范围，关于适用范围将在后面讨论。但对于大量的任务的处理，线程池的优势表现非常卓越，服务器程序处理请求的时间虽然有波动，但是其平均值相对小多了。
值得注意的是测试方案中，统计任务的完成时间没有包含了创建线程池的时间。在实际线程池工作时，即利用线程池处理任务时，创建线程池的时间是不必计算在内的。
由于测试驱动程序有很多同步代码，特别是等待线程执行完毕的同步（代码中为sleepToWait(long l)方法的调用），这些代码降低了代码执行效率，这是测试驱动一个缺点，但这个测试驱动可以说明线程池相对于简单使用线程的优势。
幸勇 一位软件设计开发者。爱好广泛。
?
