Tomcat修正JDK原生線程池bug的實(shí)現(xiàn)原理
為提高處理能力和并發(fā)度,Web容器一般會把處理請求的任務(wù)放到線程池,而JDK的原生線程池先天適合CPU密集型任務(wù),于是Tomcat改造之。
Tomcat 線程池原理
其實(shí)ThreadPoolExecutor的參數(shù)主要有如下關(guān)鍵點(diǎn):
限制線程個數(shù)
限制隊(duì)列長度
而Tomcat對這倆資源都需要限制,否則高并發(fā)下CPU、內(nèi)存都有被耗盡可能。
因此Tomcat的線程池傳參:
// 定制的任務(wù)隊(duì)列 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)
- 最大線程池?cái)?shù)(maxThreads)
Tomcat線程池還有自己的特色任務(wù)處理流程,通過重寫execute方法實(shí)現(xiàn)了自己的特色任務(wù)處理邏輯:
- 前corePoolSize個任務(wù)時,來一個任務(wù)就創(chuàng)建一個新線程
- 再有任務(wù),就把任務(wù)放入任務(wù)隊(duì)列,讓所有線程去搶。若隊(duì)列滿,就創(chuàng)建臨時線程
- 總線程數(shù)達(dá)到maximumPoolSize,則繼續(xù)嘗試把任務(wù)放入任務(wù)隊(duì)列
- 若緩沖隊(duì)列也滿了,插入失敗,執(zhí)行拒絕策略
和 JDK 線程池的區(qū)別就在step3,Tomcat在線程總數(shù)達(dá)到最大數(shù)時,不是立即執(zhí)行拒絕策略,而是再嘗試向任務(wù)隊(duì)列添加任務(wù),添加失敗后再執(zhí)行拒絕策略。
具體又是如何實(shí)現(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ù)隊(duì)列 if (!queue.force(command, timeout, unit)) { submittedCount.decrementAndGet(); // 若緩沖隊(duì)列還是滿了,插入失敗,執(zhí)行拒絕策略。 throw new RejectedExecutionException("..."); } } } } }
定制任務(wù)隊(duì)列
Tomcat線程池的execute方法第一行:
submittedCount.incrementAndGet();
任務(wù)執(zhí)行失敗,拋異常時,將該計(jì)數(shù)器減一:
submittedCount.decrementAndGet();
Tomcat線程池使用 submittedCount 變量維護(hù)已提交到線程池,但未執(zhí)行完的任務(wù)數(shù)量。
為何要維護(hù)這樣一個變量呢?
Tomcat的任務(wù)隊(duì)列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ù)隊(duì)列,并且總會成功,就永遠(yuǎn)無機(jī)會創(chuàng)建新線程了。
為解決該問題,TaskQueue重寫了LinkedBlockingQueue#offer,在合適時機(jī)返回false,表示任務(wù)添加失敗,這時線程池就會創(chuàng)建新線程。
什么叫合適時機(jī)?
public class TaskQueue extends LinkedBlockingQueue<Runnable> { ... @Override // 線程池調(diào)用任務(wù)隊(duì)列的方法時,當(dāng)前線程數(shù) > core線程數(shù) public boolean offer(Runnable o) { // 若線程數(shù)已達(dá)max,則不能創(chuàng)建新線程,只能放入任務(wù)隊(duì)列 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ù)隊(duì)列 return super.offer(o); } }
所以Tomcat維護(hù) 已提交任務(wù)數(shù) 是為了在任務(wù)隊(duì)列長度無限時,讓線程池還能有機(jī)會創(chuàng)建新線程。
到此這篇關(guān)于Tomcat是如何修正JDK原生線程池bug的的文章就介紹到這了,更多相關(guān)Tomcat JDK原生線程池內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家!
相關(guān)文章
同一臺服務(wù)器(電腦)運(yùn)行多個Tomcat的設(shè)置方法步驟
這篇文章主要介紹了同一臺服務(wù)器(電腦)運(yùn)行多個Tomcat的設(shè)置方法步驟,小編覺得挺不錯的,現(xiàn)在分享給大家,也給大家做個參考。一起跟隨小編過來看看吧2017-04-04tomcat logs 目錄下各日志文件的解析(小結(jié))
這篇文章主要介紹了tomcat logs 目錄下各日志文件的含義,包括catalina.日期.log,commons-daemon.日期.log,host-manager.日期.log,本文給大家介紹的非常詳細(xì),需要的朋友可以參考下2021-12-12