Java EE应用中的性能问题解决方案 — 第二部分 Java EE线程池调整优化(B)

声明：本文禁止未经本人同意的任何形式转载！如有转载需求，可与本人通过个人资料中的电子邮箱联系。对于未经同意的转载，本人将保留进一步行动的权利

Java的调优文档中很少建议确切的线程池大小的值。因为该值关系到应用的具体情况，比如简单和复杂类型的应用就不能混为一谈。
 
一个应用从内存中检索字符串并转发到JSP页面做展现。
另一个应用，从数据库中检索1000条记录，并计算平均值、方差。
 
第一个应用系统的响应速度较快，例如在0.25秒左右，也不需要耗费太多CPU的时间。第二个应用的响应时间大概在3秒左右，且对CPU敏感(即需要很多CPU的计算能力)。因此，在配置线程池时，给第一个应用配置100个线程就可能太低了，因为它能同时处理起码200个以上的并发请求；但100对第二个应用来说可能就太高了，因为CPU可能最大能承受50个并发线程。
但是，显示中大部分应用都是相似性很高的，所以可以考虑每个CPU配置50到75个线程。对于不同的应用，这个数字的适应性也不同，可根据对CPU监测的结果来做相应的调整。
 
线程池太大
除了可能将线程池配置得太小外，也有可能线程配置得太多了。在这种情况下，当系统负载增加时，CPU利用率持续保持很高，响应时间很长，因为CPU在不同的线程上下文之间切换工作上花费了太多的时间，而在执行工作方面的时间却显得有限了。
 
线程池太大的一个重要表现就是CPU利用率持续走高。很多情况下，CPU的利用率与垃圾收集有关，但垃圾收集造成的CPU利用率高与线程池过大造成的有一个重要的区别在于：垃圾收集造成CPU的陡升陡降，而线程池的过饱和状态则会造成CPU的持续偏高。
 
当这种情况发生时，减少线程池大小可能导致请求的等待，但是等待比在CPU饱和状态下的处理要好，因为饱和状态的CPU会表现出极差的性能。最好的情况是请求到来了，就在队列中等待一段时间，然后再利用较优化情况(非饱和状态下)的CPU进行处理。
 
解决线程池过大的问题，就需要降低线程池的大小直至在通常的负荷状态下，CPU的利用率在75%~85%之间。如果队列的大小不易于管理，则可以：
调整代码
添加新硬件
未完待续……
Java EE应用中的性能问题解决方案参考资料下载
声明：本文禁止未经本人同意的任何形式转载！如有转载需求，可与本人通过个人资料中的电子邮箱联系。对于未经同意的转载，本人将保留进一步行动的权利！

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/BU_BetterYou/archive/2008/06/03/2506586.aspx