JavaEE线程池调整优化

线程池:

 

当Web应用服务器接受到一个请求后,它将请求放置到请求队列,让执行线程来处理,这就是Web应用服务器的主要入口途径.在对内存进行调优后,对应用影响较大的调优选项就是执行线程池的尺寸配置.线程池的大小控制着并发处理请求的能力.如果线程池太小,请求将在队列中等待较长时间;如果池的尺寸太大,CPU就会在不同线程的上下文切换上花费过多的时间.

 

每个服务器都有监听的socket.接受到请求后,请求被放置到执行队列中,然后请求被一个执行线程从执行队列中移出并执行.下面显示了服务器中组成请求处理架构的组件

 

 

 

 

线程池过小:

 

当用户数上升应用性能降低或吞吐量下降时,首先检查线程池.应该明确查看以下信息:

线程池利用率

请求等待数量(队列深度)

 

 

如果线程池的利用率达到100%,并且有请求处于等待状态,这时的响应时间就会明显降低.此时,CPU的利用率可能也不高,因为应用服务器没有足够多的工作让CPU持续繁忙.此时应该逐步扩大线程池,监控应用的吞吐量直至响应时间降低。在整个过程中需要保持持续的负荷确保对性能评估的准确性。当观察到吞吐量非常稳定后,就可逐步降低线程池的大小,直至应用刚好能够输出最大吞吐量的尺寸。

 

 

下图显示线程池大小的情况:

 

 

 

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%之间.如果队列的大小不易于管理

则可以:

 

调整代码

 

添加新硬件