Tomcat修正JDK原生線程池bug的實現(xiàn)原理
為提高處理能力和并發(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ù)處理邏輯:
- 前corePoolSize個任務(wù)時,來一個任務(wù)就創(chuàng)建一個新線程
- 再有任務(wù),就把任務(wù)放入任務(wù)隊列,讓所有線程去搶。若隊列滿,就創(chuàng)建臨時線程
- 總線程數(shù)達(dá)到maximumPoolSize,則繼續(xù)嘗試把任務(wù)放入任務(wù)隊列
- 若緩沖隊列也滿了,插入失敗,執(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)無機(jī)會創(chuàng)建新線程了。
為解決該問題,TaskQueue重寫了LinkedBlockingQueue#offer,在合適時機(jī)返回false,表示任務(wù)添加失敗,這時線程池就會創(chuàng)建新線程。
什么叫合適時機(jī)?
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ù)隊列長度無限時,讓線程池還能有機(jī)會創(chuàng)建新線程。
到此這篇關(guān)于Tomcat是如何修正JDK原生線程池bug的的文章就介紹到這了,更多相關(guān)Tomcat JDK原生線程池內(nèi)容請搜索以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持!
相關(guān)文章:
1. Tomcat進(jìn)程占用CPU過高的解決方法2. 詳解Tomcat中Filter的執(zhí)行流程3. centos環(huán)境下使用tomcat 部署SpringBoot的war包4. Nginx修改默認(rèn)80端口(解決跟Tomcat的端口沖突)5. zabbix監(jiān)控Nginx/Tomcat/MySQL的詳細(xì)教程6. 使用IDEA創(chuàng)建Web項目并發(fā)布到tomcat的操作方法7. Tomcat啟動報錯:嚴(yán)重: Unable to process Jar entry [module-info.class]8. Tomcat安裝使用及部署Web項目的3種方法匯總9. 基于IDEA部署Tomcat服務(wù)器的步驟詳解10. 關(guān)于Tomcat的服務(wù)器使用及說明
