好得很程序员自学网

<tfoot draggable='sEl'></tfoot>

Tomcat如何修正JDK原生线程池Bug?

为提高处理能力和并发度,Web容器一般会把处理请求的任务放到 线程池 ,而 JDK 的原生线程池先天适合CPU密集型任务,并不适合我们通常的 I/O 密集任务处理,于是 Tomcat 改造之。

Tomcat 线程池原理

其实ThreadPoolExecutor的参数主要有如下关键点:

限制线程个数 

限制队列长度

而Tomcat对这俩资源都需要限制,否则高并发下CPU、内存都有被耗尽可能。因此Tomcat的线程池传参:

// 定制的任务队列  taskqueue = new TaskQueue(maxQueueSize);    // 定制的线程工厂  TaskThreadFactory tf = new TaskThreadFactory(namePrefix,                                 daemon,                                 getThreadPriority()  );    // 定制线程池  executor = new ThreadPoolExecutor(getMinSpareThreads(),                    getMaxThreads(),                       maxIdleTime,                        TimeUnit.MILLISECONDS,                       taskqueue,                       tf); 

Tomcat对线程数也有限制,设置:

核心线程数(minSpareThreads) 最大线程池数(maxThreads)

Tomcat线程池还有自己的特色任务处理流程,通过重写execute方法实现了自己的特色任务处理逻辑:

前corePoolSize个任务时,来一个任务就创建一个新线程 再有任务,就把任务放入任务队列,让所有线程去抢。若队列满,就创建临时线程 总线程数达到maximumPoolSize,则继续尝试把任务放入任务队列 若缓冲队列也满了,插入失败,执行拒绝策略

和 JDK 线程池的区别就在step3,Tomcat在线程总数达到最大数时,不是立即执行拒绝策略,而是再尝试向任务队列添加任务,添加失败后再执行拒绝策略。

具体又是如何实现的呢?

public  void  execute (Runnable command, long timeout, TimeUnit unit) {      submittedCount.incrementAndGet();      try {          // 调用JDK原生线程池的 execute 执行任务          super. execute (command);      } catch (RejectedExecutionException rx) {         // 总线程数达到maximumPoolSize后,JDK原生线程池会执行默认拒绝策略          if (super.getQueue() instanceof TaskQueue) {              final TaskQueue queue = (TaskQueue)super.getQueue();              try {                  // 继续尝试把任务放入任务队列                  if (!queue. force (command, timeout, unit)) {                      submittedCount.decrementAndGet();                      // 若缓冲队列还是满了,插入失败,执行拒绝策略。                      throw new RejectedExecutionException( "..." );                  }              }           }      }  } 

定制任务队列

Tomcat线程池的execute方法第一行:

submittedCount.incrementAndGet(); 

任务执行失败,抛异常时,将该计数器减一:

submittedCount.decrementAndGet(); 

Tomcat线程池使用 submittedCount 变量维护已提交到线程池,但未执行完的任务数量。

为何要维护这样一个变量呢?

Tomcat的任务队列TaskQueue扩展了JDK的LinkedBlockingQueue,Tomcat给了它一个capacity,传给父类LinkedBlockingQueue的构造器。

public  class TaskQueue extends LinkedBlockingQueue<Runnable> {       public  TaskQueue( int  capacity) {        super(capacity);    }    ...  } 

capacity参数通过Tomcat的 maxQueueSize 参数设置,但maxQueueSize默认值为Integer.MAX_VALUE:这样,当前线程数达到核心线程数后,再来的任务,线程池会把任务添加到任务队列,并且总会成功,就永远无机会创建新线程了。

为此,TaskQueue重写了LinkedBlockingQueue#offer,在合适时机返回false,表示任务添加失败,线程池此时会创建新的线程。

什么叫合适时机?

public  class TaskQueue extends LinkedBlockingQueue<Runnable> {      ...     @Override    // 线程池调用任务队列的方法时,当前线程数 > core线程数     public  boolean offer(Runnable o) {          // 若线程数已达 max ,则不能创建新线程,只能放入任务队列        if (parent.getPoolSize() == parent.getMaximumPoolSize())              return  super.offer(o);                    // 至此,表明  max 线程数 > 当前线程数 > core线程数        // 说明可创建新线程:                // 1. 若已提交任务数 < 当前线程数        //    表明还有空闲线程,无需创建新线程        if (parent.getSubmittedCount()<=(parent.getPoolSize()))              return  super.offer(o);                    // 2. 若已提交任务数 > 当前线程数        //    线程不够用了,返回 false 去创建新线程        if (parent.getPoolSize()<parent.getMaximumPoolSize())              return   false ;                    // 默认情况下总是把任务放入任务队列         return  super.offer(o);    }      } 

所以Tomcat维护 已提交任务数 是为了在任务队列长度无限时,让线程池还能有机会创建新线程。

原文链接:https://mp.weixin.qq测试数据/s/7MOOhnI5qsoi8uAihLXy7A

查看更多关于Tomcat如何修正JDK原生线程池Bug?的详细内容...

  阅读:10次