1.概述

       在正式进入Tomcat线程池之前，小伙伴们可以先回顾一下JDK中的线程池相关特性，对于JDK线程池的总结和源码的解析感兴趣的童鞋，也可参考博主的层层剖析线程池源码的这篇文章，文章主要讲述对线程池的生命周期，核心参数，常用线程池以及线程池源码做了详细的介绍。
        tomcat内部线程池的实现没有直接使用JUC下的ThreadPoolExecutor，而是选择继承JUC下的Executor体系类，然后重写execute()等方法，如下，为tomcat7.x下的线程池类图：

• tomcat的线程池不仅继承了JDK线程池Executor框架，同时为了将Executor纳入Lifecycle生命周期管理，也让它实现了Lifecycle接口
• tomcat线程池对外暴露

注意：不同版本下的tomcat，继承体系略有不同:

1. 继承JUC原生ThreadPoolExecutor（7.x版本及以下），并覆写了一些方法，主要execute()和afterExecute()

2. 继承JUC的AbstractExecutorService（7.x版本以上），从java.util.concurrent.ThreadPoolExecutor
   复制出一套代码，然后微调内部的execute()方法

2. Tomcat 线程池源码

2.1 线程池初始化

  protected void startInternal() throws LifecycleException {// 1.任务队列 taskqueue = new TaskQueue(maxQueueSize);// 2. 线程工厂TaskThreadFactory tf = new TaskThreadFactory(namePrefix,daemon,getThreadPriority());// 3. 创建线程池，// ThreadPoolExecutor为 org.apache.tomcat.util.threads.ThreadPoolExecutorexecutor = new ThreadPoolExecutor(getMinSpareThreads(), getMaxThreads(), maxIdleTime, TimeUnit.MILLISECONDS,taskqueue, tf);// 重建线程的时间间隔executor.setThreadRenewalDelay(threadRenewalDelay);// 是否需要预热核心线程if (prestartminSpareThreads) {executor.prestartAllCoreThreads();}// 线程池任务队列的 parent ,重点属性taskqueue.setParent(executor);// 设置组件的生命周期状态,lifcle 管理setState(LifecycleState.STARTING);}

在这个方法中，主要是初始化初始化org.apache.tomcat.util.threads.TaskQueue，同时构造org.apache.tomcat.util.threads.ThreadPoolExecutor的实例，org.apache.tomcat.util.threads.ThreadPoolExecutor构造方法与Java原生的线程池并没有任何不同，核心逻辑是直接调用父类[java.util.concurrent.ThreadPoolExecutor]的构造方法，只不过，在调用父类的构造方法之后，又调用了prestartAllCoreThreads（）方法，用来预热核心线程。

2.2 核心逻辑-任务执行

在进入核心executor方法之前，先上图，演示tomcat线程池中的线程池是怎么处理提交过来的任务，小伙伴可仔细观察与原生JDK线程处理有何异同：

        是不是很奇怪，与我们JDK线程池老八股文貌似有很大不同，这里是核心线程数如果满了，就判断最大线程数是否已经满了，如果没有满，则创建最大线程数；而JDK的原生线程池的的处理流是：

• 如果workerCount < corePoolSize，则创建并启动一个线程来执行新提交的任务。
• 如果workerCount >= corePoolSize，且线程池内的阻塞队列未满，则将任务添加到该阻塞队列中。
• 如果workerCount >= corePoolSize && workerCount < maximumPoolSize，且线程池内的阻塞队列已满，则创建 并启动一个线程来执行新提交的任务。
• 如果workerCount >= maximumPoolSize，并且线程池内的阻塞队列已满, 则根据拒绝策略来处理该任务, 默认的处理方式是直接抛异常

带着这个问题，直接看核心executor方法：

    public void execute(Runnable command, long timeout, TimeUnit unit) {if ( executor != null ) {// 调用org.apache.tomcat.util.threads.ThreadPoolExecutorexecutor.execute(command,timeout,unit);} else {throw new IllegalStateException("StandardThreadExecutor not started.");}}// org.apache.tomcat.util.threads.ThreadPoolExecutorpublic void execute(Runnable command, long timeout, TimeUnit unit) {// 线程任务数加qsubmittedCount.incrementAndGet();try {// 父类：java.util.concurrent.ThreadPoolExecutor#execute()方法super.execute(command);} catch (RejectedExecutionException rx) {if (super.getQueue() instanceof TaskQueue) {// 如果调用父类中的方法执行，会尝试将任务再一次放入到等待队列里final TaskQueue queue = (TaskQueue)super.getQueue();try {if (!queue.force(command, timeout, unit)) {// 如果也失败了，就回滚提交计数，并抛出异常submittedCount.decrementAndGet();throw new RejectedExecutionException(sm.getString("threadPoolExecutor.queueFull"));}} catch (InterruptedException x) {submittedCount.decrementAndGet();throw new RejectedExecutionException(x);}} else {submittedCount.decrementAndGet();throw rx;}}}

        可能看了一遍，也没发现有啥不同，Tomcat的线程池不就是调用原生的JDK线程池，然后在原生线程池执行拒绝策略的时候，尝试将任务再入一次任务队列，看起来貌似也没有毛病，不知道小伙伴有没有想起我们线程池的七大参数，在我们tomcat初始化的时候，传入的七大参数分别是什么：在Tomcat的线程池初始化的时候，其中尤其的阻塞队列，tomcat自己实现了的阻塞队列：org.apache.tomcat.util.threads.TaskQueue，其实问题就出现在该阻塞队列的实现上，下面，我们再看看org.apache.tomcat.util.threads.TaskQueue的源码

2.2.1 org.apache.tomcat.util.threads.TaskQueue

org.apache.tomcat.util.threads.TaskQueue 继承java.util.concurrent.LinkedBlockingQueue，java.util.concurrent.LinkedBlockingQueue 在初始化的时候，如果不指定默认长度，则其默认长度为Integer.MAX_VALUE

2.2.1.2 TaskQueue#offer方法

    public boolean offer(Runnable o) {//we can't do any checksif (parent==null) {return super.offer(o);}//we are maxed out on threads, simply queue the object//核心线程数等于最大线程数时if (parent.getPoolSize() == parent.getMaximumPoolSize()) {return super.offer(o);}// 提交任务的个数小于核心线程数if (parent.getSubmittedCount()<=(parent.getPoolSize())) {return super.offer(o);}// 这种情况下线程池可以直接消费任务，无需放入任务队列等待，当核心线程数小于最大线程数// 时候,直接返回falseif (parent.getPoolSize()return false;}//if we reached here, we need to add it to the queuereturn super.offer(o);}

        为什么分析org.apache.tomcat.util.threads.TaskQueue#offer() 方法呢?因为在JDK原生线程池中，如果核心线程数已满，则会调用阻塞队列的offer() 方法向队列添加任务，如果添加失败，则创建核心最大线程来处理任务，试想，此处，如果最大线程数大于核心线程数，提交任务的时候，是不是直接就返回false，然后创建最大线程数的线程来处理任务，当最大线程数满的时候，执行拒绝策略-可参考层层剖析线程池源码第3章节源码解析，JDK原生线程池抛出异常，tomcat线程池然后通过org.apache.tomcat.util.threads.TaskQueue#force()方法添加任务：如下：为org.apache.tomcat.util.threads.TaskQueue#force()源码：

public boolean force(Runnable o, long timeout, TimeUnit unit) throws InterruptedException {if (this.parent != null && !this.parent.isShutdown()) {return super.offer(o, timeout, unit);} else {throw new RejectedExecutionException("Executor not running, can't force a command into the queue");}}

         org.apache.tomcat.util.threads.TaskQueue#force() 方法很简单，本质就是调用java.util.concurrent.LinkedBlockingQueue 的offer() 方法，这样是不是很巧妙的修改了JDK原生线程池的执行流程

2.3 tomcat线程池默认属性

3.总结

tomcat 的线程池封装其实并不厚重，只是对 jdk 线程池做了简单优化，当线程池没有达到最大执行线程的时候，会优先开线程处理而不是直接将任务放入任务队列中，可能这样做，本身也是符合Tomcat的特性，因为Tomcat的处理的任务是IO请求，如果IO请求都是先放到任务队列等待，然后再处理，可能会极大降低tomcat的IO处理效率，这也是博主个人的思考，有不同看法的，欢迎留下评论，一起探讨。