引言

上一篇線程池+ FutureTask異步執(zhí)行多任務(wù)只介紹了怎么搭配使用線程池，但沒有說(shuō)明里面的線程池的參數(shù)是怎么設(shè)置的，那么本文就說(shuō)明一下。

這里把上篇文章的線程池參數(shù)設(shè)置貼出來(lái)：

//給這個(gè)接口的線程池定義里邊的線程名字
ThreadFactory namedThreadFactory = new ThreadFactoryBuilder(）.setNameFormat("thread-start-runner-%d").build();
ExecutorService taskExe= new ThreadPoolExecutor(10,20,800L, TimeUnit.MILLISECONDS,new LinkedBlockingQueue<Runnable>(100),namedThreadFactory);

這些參數(shù)也不都是隨意設(shè)置的，而是有一定的考量思路，下面會(huì)一 一介紹

先介紹一下線程池的構(gòu)造函數(shù)

public ThreadPoolExecutor(int corePoolSize,
                          int maximumPoolSize,
                          long keepAliveTime,
                          TimeUnit unit,
                          BlockingQueue<Runnable> workQueue,
                          ThreadFactory threadFactory,
                          RejectedExecutionHandler handler) {
    ...
}

我們創(chuàng)建線程池一般是手動(dòng)設(shè)置線程池的參數(shù)，已經(jīng)不建議使用Executors的FixedThreadPool 、SingleThreadPool、CachedThreadPool了

因?yàn)椋?/p>

• FixedThreadPool 、SingleThreadPool會(huì)的任務(wù)等待隊(duì)列均為new LinkedBlockingQueue<Runnable>()，允許的隊(duì)列長(zhǎng)度為 Integer.MAX_VALUE，存在任務(wù)堆積導(dǎo)致OOM內(nèi)存溢出的隱患
• 而CachedThreadPool允許的最大線程數(shù)量為Integer.MAX_VALUE，而且核心線程數(shù)為0，意味著 只要有任務(wù)進(jìn)來(lái)，就會(huì)頻繁創(chuàng)建新線程，沒有任務(wù)之后又要關(guān)閉線程，耗費(fèi)性能。另一方面，由于允許創(chuàng)建大量的線程，也有導(dǎo)致OOM的潛在隱患

設(shè)置線程池參數(shù)需要參考幾個(gè)數(shù)值：

tasks：每秒任務(wù)數(shù)，運(yùn)維反饋是平均每秒 38個(gè)

taskcost：每個(gè)任務(wù)花費(fèi)時(shí)間，0.2s

(3) responsetime：系統(tǒng)容忍(線程等待最長(zhǎng)時(shí)間)的最大時(shí)間1s

corePoolSize：核心線程數(shù)

核心線程會(huì)一直存活，不管空不空閑，但如果設(shè)置了setAllowCoreThreadTimeout(true)會(huì)讓核心線程在空閑超時(shí)后關(guān)閉

計(jì)算方式：corePoolSize=tasks/(1/taskcost) =tasks * taskcost =38*0.2=7.6 個(gè)

查閱了下文章，大佬說(shuō)計(jì)算密集型(遍歷+判斷的邏輯耗時(shí)占比多)的接口可將核心線程設(shè)置為：

corePoolSize=CPU核數(shù)+1 =8+1=9，設(shè)置為10就好了

如何查看CPU核數(shù)：

System.out.println(Runtime.getRuntime().availableProcessors());

設(shè)置得稍微大一點(diǎn)，也能減少頻繁創(chuàng)建額外線程帶來(lái)的開銷

maxPoolSize：最大線程數(shù)

如果核心線程數(shù)不夠用，會(huì)創(chuàng)建額外的線程來(lái)執(zhí)行任務(wù)。

創(chuàng)建額外線程的條件(缺一不可)：

• 現(xiàn)有的線程數(shù)< 最大線程數(shù)maxPoolSize and 現(xiàn)有線程數(shù) > corePoolSize核心線程數(shù)
• 任務(wù)隊(duì)列填滿了

最大線程數(shù)我們?cè)O(shè)置的相對(duì)隨意了些， 令maxPoolSize= 2* corePoolSize=20，大概能應(yīng)對(duì)突然暴增的業(yè)務(wù)查詢請(qǐng)求

keepAliveTime額外線程的可空閑時(shí)間

額外線程就是在核心線程數(shù)的基礎(chǔ)上 另外創(chuàng)建的線程

額外線程空閑了keepAliveTime的時(shí)間后，線程退出，直至現(xiàn)有的線程數(shù)量=corePoolSize核心線程數(shù)

• TimeUnit.MILLISECONDS是毫秒單位

workQueue任務(wù)隊(duì)列

常見的有3種：

(1) 無(wú)限隊(duì)列LinkedBlockingQueue()

構(gòu)造函數(shù)是new LinkedBlockingQueue<Runnable>()

允許的任務(wù)等待隊(duì)列的最大長(zhǎng)度為：Integer.MAX_VALUE，即能無(wú)限的接收新的任務(wù)，任何的拒絕策略也差不多沒有意義了。

另外，maximumPoolSize這個(gè)參數(shù)也沒有意義了，因?yàn)橹挥型瑫r(shí)滿足 核心線程數(shù)量夠了 + 任務(wù)隊(duì)列workQueue滿了 + 現(xiàn)有的線程數(shù)<maximumPoolSize最大線程數(shù)，才會(huì)去創(chuàng)建額外的線程

• 好處是LinkedBlockingQueue在應(yīng)對(duì)突然暴增的請(qǐng)求時(shí)，它不會(huì)拋異常拒絕
• 缺點(diǎn)是任務(wù)堆積過(guò)度沒有及時(shí)處理的話，容易導(dǎo)致內(nèi)存溢出

那咱們就不用這個(gè)隊(duì)列了吧

(2) 有界隊(duì)列

• new LinkedBlockingQueue(int capacity)：固定容量的阻塞隊(duì)列
• new ArrayBlockingQueue<Integer>(int capacity,true);其中true是公平鎖，只能FIFO排隊(duì)一 一執(zhí)行；false允許任務(wù)插隊(duì)，會(huì)存在晚來(lái)的任務(wù)先執(zhí)行的情況
• PriorityBlockingQueue(int initialCapacity, Comparator<? super E> comparator)：默認(rèn)會(huì)創(chuàng)建長(zhǎng)度為11的優(yōu)先級(jí)隊(duì)列，第二個(gè)參數(shù)comparator會(huì)按照我們指定的方式進(jìn)行排序

我們的任務(wù)基本的執(zhí)行順序基本也是先進(jìn)先出，直接用了new LinkedBlockingQueue(int capacity)，把容量設(shè)置得大一點(diǎn)，那樣就不會(huì)輕易的填滿隊(duì)列導(dǎo)致頻繁地創(chuàng)建額外的線程，減少線程頻繁切換

(3) SynchronousQueue

new SynchronousQueue()：隊(duì)列長(zhǎng)度為0，要添加新任務(wù)必須得有空閑的線程才能添加，因此要求 maximumPoolSize盡可能的大，還得 配置拒絕策略

最終， 我們選擇了new LinkedBlockingQueue(int capacity)作為任務(wù)隊(duì)列

任務(wù)隊(duì)列的長(zhǎng)度

queueCapacity = (coreSize/taskcost) * responsetime=8/0.2*1=80，隊(duì)列長(zhǎng)度設(shè)置為100也可

RejectedExecutionHandler拒絕策略

• AbortPolicy：拋異常
• DiscardPolicy：丟任務(wù)
• DiscardOldestPolicy：將隊(duì)列頭部的任務(wù)丟了，也就是把最早進(jìn)入隊(duì)列等待的任務(wù)丟了
• CallerRunsPolicy：將新任務(wù)(皮球)踢回給主線程執(zhí)行，讓主線程在接下來(lái)的時(shí)間能無(wú)法提交新任務(wù)，典型的踢皮球策略

我們選擇了默認(rèn)的AbortPolicy拋異常：

拋異常的話，需要上游系統(tǒng)截獲異常，并告知用戶請(qǐng)求繁忙稍等一下

如果是DiscardPolicy丟任務(wù)的話我猜大概率是用戶得不到響應(yīng)吧，沒這么搞過(guò)

線程工廠

它還是很有必要設(shè)置的，因?yàn)橄到y(tǒng)的線程池不止一個(gè)，不設(shè)置一下線程工廠，不給線程定義個(gè)名字的話，很難看到是哪個(gè)線程池的線程在跑，因?yàn)榫€程的名字都被寫死成pool-1-thread-1、pool-1-thread-2、pool-2-thread-1…

那么，問(wèn)題來(lái)了：如何判斷線程池里邊的指定線程是否在執(zhí)行任務(wù)？

更多關(guān)于線程池參數(shù)自定義的資料請(qǐng)關(guān)注腳本之家其它相關(guān)文章！

最新評(píng)論