在JAVA的世界里,如果想并行的执行一些任务,可以使用ThreadPoolExecutor。
大部分情况下直接使用ThreadPoolExecutor就可以满足要求了,但是在某些场景下,比如瞬时大流量的,为了提高响应和吞吐量,最好还是扩展一下ThreadPoolExecutor。
全宇宙的JAVA IT人士应该都知道ThreadPoolExecutor的执行流程:
core线程还能应付的,则不断的创建新的线程;
core线程无法应付,则将任务扔到队列里面;
队列满了(意味着插入任务失败),则开始创建MAX线程,线程数达到MAX后,队列还一直是满的,则抛出RejectedExecutionException.
这个执行流程有个小问题,就是当core线程无法应付请求的时候,会立刻将任务添加到队列中,如果队列非常长,而任务又非常多,那么将会有频繁的任务入队列和任务出队列的操作。
根据实际的压测发现,这种操作也是有一定消耗的。其实JAVA提供的SynchronousQueue队列是一个零长度的队列,任务都是直接由生产者递交给消费者,中间没有入队列的过程,可见JAVA API的设计者也是有考虑过入队列这种操作的开销。
另外,任务一多,立刻扔到队列里,而MAX线程又不干活,如果队列里面太多任务了,只有可怜的core线程在忙,也是会影响性能的。
当core线程无法应付请求的时候,能不能延后入队列这个操作呢? 让MAX线程尽快启动起来,帮忙处理任务。
也即是说,当core线程无法应付请求的时候,如果当前线程池中的线程数量还小于MAX线程数的时候,继续创建新的线程处理任务,一直到线程数量到达MAX后,才将任务插入到队列里
我们通过覆盖队列的offer方法来实现这个目标。
@Override
public boolean offer(Runnable o) {
int currentPoolThreadSize = executor.getPoolSize();
//如果线程池里的线程数量已经到达最大,将任务添加到队列中
if (currentPoolThreadSize == executor.getMaximumPoolSize()) {
return super.offer(o);
}
//说明有空闲的线程,这个时候无需创建core线程之外的线程,而是把任务直接丢到队列里即可
if (executor.getSubmittedTaskCount() < currentPoolThreadSize) {
return super.offer(o);
}
//如果线程池里的线程数量还没有到达最大,直接创建线程,而不是把任务丢到队列里面
if (currentPoolThreadSize < executor.getMaximumPoolSize()) {
return false;
}
return super.offer(o);
}
注意其中的
if (executor.getSubmittedTaskCount() < currentPoolThreadSize) {
return super.offer(o);
}
是表示core线程仍然能处理的来,同时又有空闲线程的情况,将任务插入到队列中。 如何判断线程池中有空闲线程呢? 可以使用一个计数器来实现,每当execute方法被执行的时候,计算器加1,当afterExecute被执行后,计数器减1.
@Override
public void execute(Runnable command) {
submittedTaskCount.incrementAndGet();
//代码未完整,待补充。。。。。
}
@Override
protected void afterExecute(Runnable r, Throwable t) {
submittedTaskCount.decrementAndGet();
}
这样,当
executor.getSubmittedTaskCount() < currentPoolThreadSize
的时候,说明有空闲线程。