快捷導(dǎo)航

java線程池參數(shù)自定義設(shè)置詳解

更新時間：2023年11月15日 10:11:54 作者：zhongh?Jim

這篇文章主要為大家介紹了java線程池參數(shù)自定義設(shè)置詳解,有需要的朋友可以借鑒參考下,希望能夠有所幫助,祝大家多多進(jìn)步,早日升職加薪

引言

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

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

//給這個接口的線程池定義里邊的線程名字
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è)置的，而是有一定的考量思路，下面會一一介紹

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

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

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

因為：

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

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

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

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

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

corePoolSize：核心線程數(shù)

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

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

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

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

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

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

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

maxPoolSize：最大線程數(shù)

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

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

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

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

keepAliveTime額外線程的可空閑時間

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

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

TimeUnit.MILLISECONDS是毫秒單位

workQueue任務(wù)隊列

常見的有3種：

(1) 無限隊列LinkedBlockingQueue()

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

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

另外，maximumPoolSize這個參數(shù)也沒有意義了，因為只有同時滿足 核心線程數(shù)量夠了 + 任務(wù)隊列workQueue滿了 + 現(xiàn)有的線程數(shù)<maximumPoolSize最大線程數(shù)，才會去創(chuàng)建額外的線程

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

那咱們就不用這個隊列了吧

(2) 有界隊列

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

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