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)
- 前corePoolSize个任务时,来一个任务就创建一个新线程
- 再有任务,就把任务放入任务队列,让所有线程去抢。若队列满,就创建临时线程
- 总线程数达到maximumPoolSize,则继续尝试把任务放入任务队列
- 若缓冲队列也满了,插入失败,执行拒绝策略
具体又是如何实现的呢?
文章图片
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{public TaskQueue(int capacity) {super(capacity); }...}
capacity参数通过Tomcat的maxQueueSize参数设置,但maxQueueSize默认值Integer.MAX_VALUE:当前线程数达到核心线程数后,再来任务的话线程池会把任务添加到任务队列,并且总会成功,就永远无机会创建新线程了。
为解决该问题,TaskQueue重写了LinkedBlockingQueue#offer,在合适时机返回false,表示任务添加失败,这时线程池就会创建新线程。
什么叫合适时机?
public class TaskQueue extends LinkedBlockingQueue{...@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() 所以Tomcat维护 已提交任务数 是为了在任务队列长度无限时,让线程池还能有机会创建新线程。
【Tomcat修正JDK原生线程池bug的实现原理】到此这篇关于Tomcat是如何修正JDK原生线程池bug的的文章就介绍到这了,更多相关Tomcat JDK原生线程池内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家!
推荐阅读
- Linux下面如何查看tomcat已经使用多少线程
- 探索免费开源服务器tomcat的魅力
- oracle|oracle java jdk install
- Tomcat8带来的坑
- maven使用tomcat7插件编译jsp出错
- Nginx|Nginx Tomcat 构造https服务应对苹果要求
- 【Tomcat源码阅读分享】—(5)Tomcat中的ClassLoader
- java动态代理技术解析
- 5.|5. JDK8的并行数据处理
- 制作jdk8|制作jdk8 Dockerfile