Tomcat修正JDK原生线程池bug的实现原理
脚本宝典收集整理的这篇文章主要介绍了Tomcat修正JDK原生线程池bug的实现原理，脚本宝典觉得挺不错的，现在分享给大家，也给大家做个参考。
为提高处理能力和并发度，Web容器一般会把处理请求的任务放到线程池，而JDK的原生线程池先天适合CPU密集型任务，于是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维护 已提交任务数 是为了在任务队列长度无限时，让线程池还能有机会创建新线程。
到此这篇关于Tomcat是如何修正JDK原生线程池bug的的文章就介绍到这了,更多相关Tomcat JDK原生线程池内容请搜索脚本宝典以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本宝典！
脚本宝典总结
以上是脚本宝典为你收集整理的Tomcat修正JDK原生线程池bug的实现原理全部内容，希望文章能够帮你解决Tomcat修正JDK原生线程池bug的实现原理所遇到的问题。
本图文内容来源于网友网络收集整理提供，作为学习参考使用，版权属于原作者。
如您有任何意见或建议可联系处理。小编QQ：384754419，请注明来意。
- tomcat 6.0.20在一个机器上安装多个服务的方法 2022-04-24
- 使用jenkins将项目部署到另一台主机的过程 2022-04-24
- tomcat+nginx实现多应用部署的示例代码 2022-04-24
- Tomcat服务器入门超详细教程 2022-04-24
- Tomcat的类加载机制流程及源码解析 2022-04-24
- 一篇文章讲透Tomcat的类加载机制 2022-04-24
- 教你如何通过JConsoler监控Tomcat的JVM内存 2022-04-24
- 关于Tomcat 结合Atomikos 实现JTA的方法 2022-04-24
- tomcat logs 目录下各日志文件的解析(小结) 2022-04-24
- eclipse配置Tomcat和Tomcat出现无效端口解决办法 2022-04-24