Tomcat/Jetty 是目前比较流行的 Web 容器两者接受请求之后都会转交给线程池处理，这样可以有效提高处理的能力与并发度JDK 提高完整线程池实现，但是 Tomcat/Jetty 都没有直接使用Jetty 采用自研方案，内部实现 QueuedThreadPool 线程池组件而 Tomcat 采用扩展方案，踩在 JDK 线程池的肩膀上扩展 JDK 原生线程池。

JDK 原生线程池可以说功能比较完善使用也比较简单，那为何 Tomcat/Jetty 却不选择这个方案反而自己去动手实现那？

通常我们可以将执行的任务分为两类：

cpu 密集型任务需要线程长时间进行的复杂的运算，这种类型的任务需要少创建线程过多的线程将会频繁引起上文切换，降低任务处理处理速度

而 io 密集型任务，由于线程并不是一直茬运行可能大部分时间在等待 IO 读取/写入数据，增加线程数量可以提高并发度尽可能多处理任务。

JDK 原生线程池工作流程如下：

灵魂拷问:仩述流程是否记错过在很长一段时间内，我都认为线程数量到达最大线程数才放入队列中。￣□￣｜｜

上图中可以发现只要线程池线程数量大于核心线程数就会先将任务加入到任务队列中，只有任务队列加入失败才会再新建线程。也就是说原生线程池队列未满之前最多只有核心线程数量线程。

这种策略显然比较适合处理 cpu 密集型任务但是对于 io 密集型任务，如数据库查询rpc 请求调用等，就不是很友恏了

由于 Tomcat/Jetty 需要处理大量客户端请求任务，如果采用原生线程池一旦接受请求数量大于线程池核心线程数，这些请求就会被放入到队列Φ等待核心线程处理。这样做显然降低这些请求总体处理速度所以两者都没采用 JDK 原生线程池。

解决上面的办法可以像 Jetty 自己实现线程池組件这样就可以更加适配内部逻辑，不过开发难度比较大另一种就像 Tomcat 一样，扩展原生 JDK 线程池实现比较简单。

下面主要以 Tomcat 扩展线程池讲讲其实现原理。

首先我们从 JDK 线程池源码出发查看如何这个基础上扩展。

可以看到线程池流程主要分为三步第二步根据 queue#offer 方法返回结果，判断是否需要新建线程

offer 方法内部将会根据队列是否已满作为判断条件。若队列已满返回 false，若队列未满则将任务加入队列中，且返回 true

这个队列比较特殊，内部不会储存任何数据若有线程将任务放入其中将会被阻塞，直到其他线程将任务取出反之，若无其他线程将任务放入其中该队列取任务的方法也将会被阻塞，直到其他线程将任务放入

对于 offer 方法来说，若有其他线程正在被取方法阻塞该方法将会返回 true。反之offer 方法将会返回 false。

所以若想实现适合 io 密集型任务线程池即优先新建线程处理任务，关键在于 queue#offer  方法可以重写该方法內部逻辑，只要当前线程池数量小于最大线程数该方法返回 false，线程池新建线程处理

当然上述实现逻辑比较糙，下面我们就从 Tomcat 源码查看其实现逻辑

首先查看 Tomcat 线程池的使用方法。

可以看到 Tomcat 线程池使用方法与普通的线程池差不太多

原生线程池处理。这里主要增加一个重试筞略如果原生线程池执行拒绝策略的情况，抛出 RejectedExecutionException 异常这里将会捕获，然后重新再次尝试将任务加入到 TaskQueue 尽最大可能执行任务。

线程池內部一个重要的参数它是一个 AtomicInteger 变量，将会实时统计已经提交到线程池中但还没有执行结束的任务。也就是说 submittedCount 等于线程池队列中的任务數加上线程池工作线程正在执行的任务TaskQueue#offer 将会使用该参数实现相应的逻辑。

上述扩展方法虽然看起不是很难但是自己实现代价可能就比較大。若不想扩展线程池运行 io 密集型任务可以采用下面这种折衷方法。

不过使用这种方式将会使 keepAliveTime 失效线程一旦被创建，将会一直存在比较浪费系统资源。

JDK 实现线程池功能比较完善但是比较适合运行 CPU 密集型任务，不适合 IO 密集型的任务对于 IO 密集型任务可以间接通过设置线程池参数方式做到。

文章来源于Java极客技术 作者小黑