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

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

Tomcat 线程池原理

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

• 限制线程个数 

• 限制队列长度

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

1. // 定制的任务队列 
2. taskqueue = new TaskQueue(maxQueueSize); 
3.  
4. // 定制的线程工厂 
5. TaskThreadFactory tf = new TaskThreadFactory(namePrefix, 
6.                                daemon, 
7.                                getThreadPriority() 
8. ); 
9.  
10. // 定制线程池 
11. executor = new ThreadPoolExecutor(getMinSpareThreads(), 
12.                   getMaxThreads(), 
13.                      maxIdleTime,  
14.                      TimeUnit.MILLISECONDS, 
15.                      taskqueue, 
16.                      tf); 

Tomcat对线程数也有限制，设置：

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

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

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

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

具体又是如何实现的呢?

1. public void execute(Runnable command, long timeout, TimeUnit unit) { 
2.     submittedCount.incrementAndGet(); 
3.     try { 
4.         // 调用JDK原生线程池的execute执行任务 
5.         super.execute(command); 
6.     } catch (RejectedExecutionException rx) { 
7.        // 总线程数达到maximumPoolSize后，JDK原生线程池会执行默认拒绝策略 
8.         if (super.getQueue() instanceof TaskQueue) { 
9.             final TaskQueue queue = (TaskQueue)super.getQueue(); 
10.             try { 
11.                 // 继续尝试把任务放入任务队列 
12.                 if (!queue.force(command, timeout, unit)) { 
13.                     submittedCount.decrementAndGet(); 
14.                     // 若缓冲队列还是满了，插入失败，执行拒绝策略。 
15.                     throw new RejectedExecutionException("..."); 
16.                 } 
17.             }  
18.         } 
19.     } 
20. } 

定制任务队列

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

1. submittedCount.incrementAndGet(); 

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

1. submittedCount.decrementAndGet(); 

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

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

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

1. public class TaskQueue extends LinkedBlockingQueue<Runnable> { 
2.  
3.   public TaskQueue(int capacity) { 
4.       super(capacity); 
5.   } 
6.   ... 
7. } 

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

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

什么叫合适时机?

1. public class TaskQueue extends LinkedBlockingQueue<Runnable> { 
2.  
3.   ... 
4.    @Override 
5.   // 线程池调用任务队列的方法时，当前线程数 ＞ core线程数 
6.   public boolean offer(Runnable o) { 
7.  
8.       // 若线程数已达max，则不能创建新线程，只能放入任务队列 
9.       if (parent.getPoolSize() == parent.getMaximumPoolSize())  
10.           return super.offer(o); 
11.            
12.       // 至此，表明 max线程数 > 当前线程数 ＞ core线程数 
13.       // 说明可创建新线程： 
14.        
15.       // 1. 若已提交任务数 ＜ 当前线程数 
16.       //    表明还有空闲线程，无需创建新线程 
17.       if (parent.getSubmittedCount()<=(parent.getPoolSize()))  
18.           return super.offer(o); 
19.            
20.       // 2. 若已提交任务数 ＞ 当前线程数 
21.       //    线程不够用了，返回false去创建新线程 
22.       if (parent.getPoolSize()<parent.getMaximumPoolSize())  
23.           return false; 
24.            
25.       // 默认情况下总是把任务放入任务队列 
26.       return super.offer(o); 
27.   } 
28.    
29. } 

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

原文链接：https://mp.weixin.qq.com/s/7MOOhnI5qsoi8uAihLXy7A