背景：JDK的線程池的運(yùn)作原理 ：

JDK的線程池的構(gòu)造函數(shù)有7個(gè)參數(shù)，分別是corePoolSize、maximumPoolSize、keepAliveTime、unit、workQueue、threadFactory、handler。先復(fù)習(xí)一下 https://blog.csdn.net/ye17186/article/details/89467919

上述內(nèi)容是網(wǎng)上對(duì)于線程池的參數(shù)的描述，需要關(guān)注的一個(gè)點(diǎn)：

1)任務(wù)進(jìn)入線程池隊(duì)列，先啟動(dòng)WORKER線程到 CORE的數(shù)量，然后再填寫線程池的緩沖隊(duì)列，隊(duì)列滿了以后(如果可以滿)，再增加WORKER線程到MAX配置數(shù)量。

下面是源碼：(源碼就是這樣，也驗(yàn)證過，是這個(gè)邏輯，簡(jiǎn)單說，先CORE 再隊(duì)列，隊(duì)列滿了以后再拉線程到MAX數(shù)量)

2)這樣會(huì)有缺陷，為什么一定要 滿足 隊(duì)列滿了，再拉線程，我想優(yōu)先拉線程怎么辦 ？ 不好意思，JDK只有一個(gè)辦法：設(shè)置隊(duì)列大小為1，那么就基本上馬上就會(huì)拉新線程了(但是作為數(shù)據(jù)緩沖區(qū)的隊(duì)列，削峰填谷的優(yōu)勢(shì)就無(wú)法使用了)

那么如果期望 優(yōu)先 先拉線程數(shù)量到MAX，再把任務(wù)放到隊(duì)列緩存區(qū)怎么辦 ？

業(yè)務(wù)場(chǎng)景需要滿足： 1)任務(wù)量大了，線程立即到拉到MAX 數(shù)量跑業(yè)務(wù)。 2)線程到MAX了，額外的隊(duì)列可以存儲(chǔ)任務(wù)，做削峰填谷使用。

(core size是閑時(shí)最低線程數(shù)量，如果線程數(shù)量太多，會(huì)導(dǎo)致線程內(nèi)存開銷以及 太多線程無(wú)效輪詢消耗)

方案一： 看到源碼，自己去實(shí)現(xiàn)一個(gè)線程池的實(shí)現(xiàn)，重寫EXECUTE方法，調(diào)整邏輯，先拉WORKER到MAX然后放入隊(duì)列可以達(dá)成

項(xiàng)目中，準(zhǔn)備上方案一的時(shí)候，發(fā)現(xiàn)代碼量不小，這個(gè)問題應(yīng)該很多人都遇到了，有沒有現(xiàn)成的可以使用？

重寫JDK源碼會(huì)帶來(lái)工作量，維護(hù)，以及升級(jí)JDK的風(fēng)險(xiǎn)，明顯是一種不好的辦法。

方案二：再找就發(fā)現(xiàn)了這樣一篇文檔：

果然，遇到這個(gè)問題的不止一個(gè)， 事實(shí)上 tomcat 和dubbo 都這樣干了！

非常有意思的是，是在隊(duì)列的OFFER函數(shù)中做文章(有點(diǎn)欺騙JDK的線程池 EXECUTE的意思)很難想到這種方案。

我們要使用：兩行代碼就滿足了我們的訴求：

引用對(duì)象：當(dāng)然是用DUBBO也是一樣，已驗(yàn)證、有效。

PS: 額外的思考：

1)為什么？JDK默認(rèn)要使用先隊(duì)列再拉MAX WORKER的方式? 可能是JDK認(rèn)為線程池任務(wù)大多數(shù)都是 CPU密集型的任務(wù)，那么啟動(dòng)太多的CPU帶來(lái)的價(jià)值不大、或者拉線程的有成本，隊(duì)列滿了再拉。

2)怎么選？如果任務(wù)是CPU密集使用JDK自帶的線程池策略就夠了，如果是IO型任務(wù)，有較多阻塞場(chǎng)景(這就是為什么TOMCAT 和RPC的DUBBO需要的原因)就需要使用線程數(shù)優(yōu)先，再進(jìn)入隊(duì)列的模式(IO密集型任務(wù)，有IO阻塞，JDK自帶線程池的策略難以滿足要求)。

3)客觀的說，JDK應(yīng)該把這個(gè)配置 做成配置項(xiàng)(到底是先進(jìn)入隊(duì)列，再拉線程到MAX，還是先拉線程到MAX再進(jìn)入隊(duì)列)

總結(jié)

以上是生活随笔為你收集整理的java如何创建一个两个数的队列_java线程池 如何构建一个线程立即到拉到MAX数量跑业务，线程到MAX了，额外的队列可以存储任务的线程池...的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。