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

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

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

引言

上一篇線程池+ FutureTask異步執(zhí)行多任務只介紹了怎么搭配使用線程池，但沒有說明里面的線程池的參數(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ù)

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

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

因為：

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

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

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

taskcost：每個任務花費時間，0.2s

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

corePoolSize：核心線程數(shù)

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

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

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

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

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

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

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

maxPoolSize：最大線程數(shù)

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

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

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

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

keepAliveTime額外線程的可空閑時間

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

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

TimeUnit.MILLISECONDS是毫秒單位

workQueue任務隊列

常見的有3種：

(1) 無限隊列LinkedBlockingQueue()

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

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

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

好處是LinkedBlockingQueue在應對突然暴增的請求時，它不會拋異常拒絕
缺點是任務堆積過度沒有及時處理的話，容易導致內存溢出

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

(2) 有界隊列

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

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