為提高處理能力和并發(fā)度，Web容器一般會把處理請求的任務(wù)放到線程池，而JDK的原生線程池先天適合CPU密集型任務(wù)，于是Tomcat改造之。

Tomcat 線程池原理

其實ThreadPoolExecutor的參數(shù)主要有如下關(guān)鍵點：

限制線程個數(shù)

限制隊列長度

而Tomcat對這倆資源都需要限制，否則高并發(fā)下CPU、內(nèi)存都有被耗盡可能。
因此Tomcat的線程池傳參：

// 定制的任務(wù)隊列taskqueue = new TaskQueue(maxQueueSize);// 定制的線程工廠TaskThreadFactory tf = new TaskThreadFactory(namePrefix,							 daemon,							 getThreadPriority());// 定制線程池executor = new ThreadPoolExecutor(getMinSpareThreads(),								  getMaxThreads(),				 			      maxIdleTime, 				 			      TimeUnit.MILLISECONDS,				 			      taskqueue,				 			      tf);

Tomcat對線程數(shù)也有限制，設(shè)置：

• 核心線程數(shù)（minSpareThreads）
• 最大線程池數(shù)（maxThreads）

Tomcat線程池還有自己的特色任務(wù)處理流程，通過重寫execute方法實現(xiàn)了自己的特色任務(wù)處理邏輯：

1. 前corePoolSize個任務(wù)時，來一個任務(wù)就創(chuàng)建一個新線程
2. 再有任務(wù)，就把任務(wù)放入任務(wù)隊列，讓所有線程去搶。若隊列滿，就創(chuàng)建臨時線程
3. 總線程數(shù)達(dá)到maximumPoolSize，則繼續(xù)嘗試把任務(wù)放入任務(wù)隊列
4. 若緩沖隊列也滿了，插入失敗，執(zhí)行拒絕策略

和 JDK 線程池的區(qū)別就在step3，Tomcat在線程總數(shù)達(dá)到最大數(shù)時，不是立即執(zhí)行拒絕策略，而是再嘗試向任務(wù)隊列添加任務(wù)，添加失敗后再執(zhí)行拒絕策略。

具體又是如何實現(xiàn)的呢？

public void execute(Runnable command, long timeout, TimeUnit unit) {    submittedCount.incrementAndGet();    try {// 調(diào)用JDK原生線程池的execute執(zhí)行任務(wù)super.execute(command);    } catch (RejectedExecutionException rx) {       // 總線程數(shù)達(dá)到maximumPoolSize后，JDK原生線程池會執(zhí)行默認(rèn)拒絕策略if (super.getQueue() instanceof TaskQueue) {    final TaskQueue queue = (TaskQueue)super.getQueue();    try {// 繼續(xù)嘗試把任務(wù)放入任務(wù)隊列if (!queue.force(command, timeout, unit)) {    submittedCount.decrementAndGet();    // 若緩沖隊列還是滿了，插入失敗，執(zhí)行拒絕策略。    throw new RejectedExecutionException("...");}    } }    }}

定制任務(wù)隊列

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

submittedCount.incrementAndGet();

任務(wù)執(zhí)行失敗，拋異常時，將該計數(shù)器減一：

submittedCount.decrementAndGet();

Tomcat線程池使用 submittedCount 變量維護(hù)已提交到線程池，但未執(zhí)行完的任務(wù)數(shù)量。

為何要維護(hù)這樣一個變量呢？

Tomcat的任務(wù)隊列TaskQueue擴(kuò)展了JDK的LinkedBlockingQueue，Tomcat給了它一個capacity，傳給父類LinkedBlockingQueue的構(gòu)造器。

public class TaskQueue extends LinkedBlockingQueue<Runnable> {  public TaskQueue(int capacity) {      super(capacity);  }  ...}

capacity參數(shù)通過Tomcat的maxQueueSize參數(shù)設(shè)置，但maxQueueSize默認(rèn)值Integer.MAX_VALUE：當(dāng)前線程數(shù)達(dá)到核心線程數(shù)后，再來任務(wù)的話線程池會把任務(wù)添加到任務(wù)隊列，并且總會成功，就永遠(yuǎn)無機會創(chuàng)建新線程了。

為解決該問題，TaskQueue重寫了LinkedBlockingQueue#offer，在合適時機返回false，表示任務(wù)添加失敗，這時線程池就會創(chuàng)建新線程。

什么叫合適時機？

public class TaskQueue extends LinkedBlockingQueue<Runnable> {  ...   @Override  // 線程池調(diào)用任務(wù)隊列的方法時，當(dāng)前線程數(shù) ＞ core線程數(shù)  public boolean offer(Runnable o) {      // 若線程數(shù)已達(dá)max，則不能創(chuàng)建新線程，只能放入任務(wù)隊列      if (parent.getPoolSize() == parent.getMaximumPoolSize())   return super.offer(o);        // 至此，表明 max線程數(shù) > 當(dāng)前線程數(shù) ＞ core線程數(shù)      // 說明可創(chuàng)建新線程：            // 1. 若已提交任務(wù)數(shù) ＜ 當(dāng)前線程數(shù)      //    表明還有空閑線程，無需創(chuàng)建新線程      if (parent.getSubmittedCount()<=(parent.getPoolSize()))   return super.offer(o);        // 2. 若已提交任務(wù)數(shù) ＞ 當(dāng)前線程數(shù)      //    線程不夠用了，返回false去創(chuàng)建新線程      if (parent.getPoolSize()<parent.getMaximumPoolSize())   return false;        // 默認(rèn)情況下總是把任務(wù)放入任務(wù)隊列      return super.offer(o);  }  }

所以Tomcat維護(hù) 已提交任務(wù)數(shù) 是為了在任務(wù)隊列長度無限時，讓線程池還能有機會創(chuàng)建新線程。

到此這篇關(guān)于Tomcat是如何修正JDK原生線程池bug的的文章就介紹到這了,更多相關(guān)Tomcat JDK原生線程池內(nèi)容請搜索以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持！