你都理解創(chuàng)建線程池的參數(shù)嗎?

微信公眾號「后端進階」,專注后端技術(shù)分享:Java、Golang、WEB框架、分布式中間件、服務(wù)治理等等。
老司機傾囊相授,帶你一路進階,來不及解釋了快上車!

多線程可以說是面試官最喜歡拿來問的題目之一了,可謂是老生之常談,不管你是新手還是老司機,我相信你一定會在面試過程中遇到過有關(guān)多線程的一些問題。那我現(xiàn)在就充當(dāng)一次面試官,我來問你:

現(xiàn)有一個線程池,參數(shù)corePoolSize = 5,maximumPoolSize = 10,BlockingQueue阻塞隊列長度為5,此時有4個任務(wù)同時進來,問:線程池會創(chuàng)建幾條線程?

如果4個任務(wù)還沒處理完,這時又同時進來2個任務(wù),問:線程池又會創(chuàng)建幾條線程還是不會創(chuàng)建?

如果前面6個任務(wù)還是沒有處理完,這時又同時進來5個任務(wù),問:線程池又會創(chuàng)建幾條線程還是不會創(chuàng)建?

如果你此時一臉懵逼,請不要慌,問題不大。

dont_panic

創(chuàng)建線程池的構(gòu)造方法的參數(shù)都有哪些?

要回答這個問題,我們需要從創(chuàng)建線程池的參數(shù)去找答案:

java.util.concurrent.ThreadPoolExecutor#ThreadPoolExecutor:

public ThreadPoolExecutor(int corePoolSize,
                          int maximumPoolSize,
                          long keepAliveTime,
                          TimeUnit unit,
                          BlockingQueue<Runnable> workQueue,
                          ThreadFactory threadFactory,
                          RejectedExecutionHandler handler) {
    if (corePoolSize < 0 || maximumPoolSize <= 0 || maximumPoolSize < corePoolSize || keepAliveTime < 0)
        throw new IllegalArgumentException();
    if (workQueue == null || threadFactory == null || handler == null)
        throw new NullPointerException();
    this.acc = System.getSecurityManager() == null ? null : AccessController.getContext();
    this.corePoolSize = corePoolSize;
    this.maximumPoolSize = maximumPoolSize;
    this.workQueue = workQueue;
    this.keepAliveTime = unit.toNanos(keepAliveTime);
    this.threadFactory = threadFactory;
    this.handler = handler;
}

創(chuàng)建線程池一共有7個參數(shù),從源碼可知,corePoolSize和maximumPoolSize都不能小于0,且核心線程數(shù)不能大于最大線程數(shù)。

下面我來解釋一下這7個參數(shù)的用途:

corePoolSize

線程池核心線程數(shù)量,核心線程不會被回收,即使沒有任務(wù)執(zhí)行,也會保持空閑狀態(tài)。

maximumPoolSize

池允許最大的線程數(shù),當(dāng)線程數(shù)量達到corePoolSize,且workQueue隊列塞滿任務(wù)了之后,繼續(xù)創(chuàng)建線程。

keepAliveTime

超過corePoolSize之后的“臨時線程”的存活時間。

unit

keepAliveTime的單位。

workQueue

當(dāng)前線程數(shù)超過corePoolSize時,新的任務(wù)會處在等待狀態(tài),并存在workQueue中,BlockingQueue是一個先進先出的阻塞式隊列實現(xiàn),底層實現(xiàn)會涉及Java并發(fā)的AQS機制,有關(guān)于AQS的相關(guān)知識,我會單獨寫一篇,敬請期待。

threadFactory

創(chuàng)建線程的工廠類,通常我們會自頂一個threadFactory設(shè)置線程的名稱,這樣我們就可以知道線程是由哪個工廠類創(chuàng)建的,可以快速定位。

handler

線程池執(zhí)行拒絕策略,當(dāng)線數(shù)量達到maximumPoolSize大小,并且workQueue也已經(jīng)塞滿了任務(wù)的情況下,線程池會調(diào)用handler拒絕策略來處理請求。

系統(tǒng)默認的拒絕策略有以下幾種:

  1. AbortPolicy:為線程池默認的拒絕策略,該策略直接拋異常處理。
  2. DiscardPolicy:直接拋棄不處理。
  3. DiscardOldestPolicy:丟棄隊列中最老的任務(wù)。
  4. CallerRunsPolicy:將任務(wù)分配給當(dāng)前執(zhí)行execute方法線程來處理。

我們還可以自定義拒絕策略,只需要實現(xiàn)RejectedExecutionHandler接口即可,友好的拒絕策略實現(xiàn)有如下:

  1. 將數(shù)據(jù)保存到數(shù)據(jù),待系統(tǒng)空閑時再進行處理
  2. 將數(shù)據(jù)用日志進行記錄,后由人工處理

現(xiàn)在我們回到剛開始的問題就很好回答了:

線程池corePoolSize=5,線程初始化時不會自動創(chuàng)建線程,所以當(dāng)有4個任務(wù)同時進來時,執(zhí)行execute方法會新建【4】條線程來執(zhí)行任務(wù);

前面的4個任務(wù)都沒完成,現(xiàn)在又進來2個隊列,會新建【1】條線程來執(zhí)行任務(wù),這時poolSize=corePoolSize,還剩下1個任務(wù),線程池會將剩下這個任務(wù)塞進阻塞隊列中,等待空閑線程執(zhí)行;

如果前面6個任務(wù)還是沒有處理完,這時又同時進來了5個任務(wù),此時還沒有空閑線程來執(zhí)行新來的任務(wù),所以線程池繼續(xù)將這5個任務(wù)塞進阻塞隊列,但發(fā)現(xiàn)阻塞隊列已經(jīng)滿了,核心線程也用完了,還剩下1個任務(wù)不知道如何是好,于是線程池只能創(chuàng)建【1】條“臨時”線程來執(zhí)行這個任務(wù)了;

這里創(chuàng)建的線程用“臨時”來描述還是因為它們不會長期存在于線程池,它們的存活時間為keepAliveTime,此后線程池會維持最少corePoolSize數(shù)量的線程。

image

為什么不建議使用Executors創(chuàng)建線程池?

JDK為我們提供了Executors線程池工具類,里面有默認的線程池創(chuàng)建策略,大概有以下幾種:

  1. FixedThreadPool:線程池線程數(shù)量固定,即corePoolSize和maximumPoolSize數(shù)量一樣。
  2. SingleThreadPool:單個線程的線程池。
  3. CachedThreadPool:初始核心線程數(shù)量為0,最大線程數(shù)量為Integer.MAX_VALUE,線程空閑時存活時間為60秒,并且它的阻塞隊列為SynchronousQueue,它的初始長度為0,這會導(dǎo)致任務(wù)每次進來都會創(chuàng)建線程來執(zhí)行,在線程空閑時,存活時間到了又會釋放線程資源。
  4. ScheduledThreadPool:創(chuàng)建一個定長的線程池,而且支持定時的以及周期性的任務(wù)執(zhí)行,類似于Timer。

用Executors工具類雖然很方便,我依然不推薦大家使用以上默認的線程池創(chuàng)建策略,阿里巴巴開發(fā)手冊也是強制不允許使用Executors來創(chuàng)建線程池,我們從JDK源碼中尋找一波答案:

java.util.concurrent.Executors:

// FixedThreadPool
public static ExecutorService newFixedThreadPool(int nThreads) {
    return new ThreadPoolExecutor(nThreads, nThreads,
                                  0L, TimeUnit.MILLISECONDS,
                                  new LinkedBlockingQueue<Runnable>());
}

// SingleThreadPool
public static ExecutorService newSingleThreadExecutor() {
    return new FinalizableDelegatedExecutorService
        (new ThreadPoolExecutor(1, 1,
                                0L, TimeUnit.MILLISECONDS,
                                new LinkedBlockingQueue<Runnable>()));
}

// CachedThreadPool
public static ExecutorService newCachedThreadPool() {
    // 允許創(chuàng)建線程數(shù)為Integer.MAX_VALUE
    return new ThreadPoolExecutor(0, Integer.MAX_VALUE,
                                  60L, TimeUnit.SECONDS,
                                  new SynchronousQueue<Runnable>());
}

// ScheduledThreadPool
public ScheduledThreadPoolExecutor(int corePoolSize) {
    // 允許創(chuàng)建線程數(shù)為Integer.MAX_VALUE
        super(corePoolSize, Integer.MAX_VALUE, 0, NANOSECONDS,
              new DelayedWorkQueue());
    }
public LinkedBlockingQueue() {
    // 允許隊列長度最大為Integer.MAX_VALUE
    this(Integer.MAX_VALUE);
}

從JDK源碼可看出,Executors工具類無非是把一些特定參數(shù)進行了封裝,并提供一些方法供我們調(diào)用而已,我們并不能靈活地填寫參數(shù),策略過于簡單,不夠友好。

CachedThreadPool和ScheduledThreadPool最大線程數(shù)為Integer.MAX_VALUE,如果線程無限地創(chuàng)建,會造成OOM異常。

LinkedBlockingQueue基于鏈表的FIFO隊列,是無界的,默認大小是Integer.MAX_VALUE,因此FixedThreadPool和SingleThreadPool的阻塞隊列長度為Integer.MAX_VALUE,如果此時隊列被無限地堆積任務(wù),會造成OOM異常。

公眾號「后端進階」,專注后端技術(shù)分享!
最后編輯于
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
【社區(qū)內(nèi)容提示】社區(qū)部分內(nèi)容疑似由AI輔助生成,瀏覽時請結(jié)合常識與多方信息審慎甄別。
平臺聲明:文章內(nèi)容(如有圖片或視頻亦包括在內(nèi))由作者上傳并發(fā)布,文章內(nèi)容僅代表作者本人觀點,簡書系信息發(fā)布平臺,僅提供信息存儲服務(wù)。

相關(guān)閱讀更多精彩內(nèi)容

友情鏈接更多精彩內(nèi)容