圖解 | 你管這玩意叫線程池？
本文轉(zhuǎn)載自微信公眾號(hào)「低并發(fā)編程」，作者閃客sun 。轉(zhuǎn)載本文請聯(lián)系低并發(fā)編程公眾號(hào)。
小宇：閃客，我最近看到線程池，被里邊亂七八槽的參數(shù)給搞暈了，你能不能給我講講呀?
閃客：沒問題，這個(gè)我擅長，咱們從一個(gè)最簡單的情況開始，假設(shè)有一段代碼，你希望異步執(zhí)行它，是不是要寫出這樣的代碼?
- new Thread(r).start();
小宇：嗯嗯，最簡單的寫法似乎就是這樣呢。
閃客：這種寫法當(dāng)然可以完成功能，可是你這樣寫，老王這樣寫，老張也這樣寫，程序中到處都是這樣創(chuàng)建線程的方法，能不能寫一個(gè)統(tǒng)一的工具類讓大家調(diào)用呢?
小宇：可以的，感覺有一個(gè)統(tǒng)一的工具類，更優(yōu)雅一些。
閃客：那如果讓你來設(shè)計(jì)這個(gè)工具類，你會(huì)怎么寫呢?我先給你定一個(gè)接口，你來實(shí)現(xiàn)。
- public interface Executor {
- public void execute(Runnable r);
- }
小宇：emmm，我可能先定義幾個(gè)成員變量，比如核心線程數(shù)、最大線程數(shù) ...反正就是那些亂七八糟的參數(shù)。
閃客：STOP!小宇呀，你現(xiàn)在深受面試手冊的毒害，你先把這些全部的概念忘掉，就說讓你寫一個(gè)最簡單的工具類，第一反應(yīng)，你會(huì)怎么寫?
第一版
小宇：那我可能會(huì)這樣
- // 新線程：直接創(chuàng)建一個(gè)新線程運(yùn)行
- class FlashExecutor implements Executor {
- public void execute(Runnable r) {
- new Thread(r).start();
- }
- }
閃客：嗯嗯很好，你的思路非常棒。
小宇：啊，我這個(gè)會(huì)不會(huì)太 low 了呀，我還以為你會(huì)罵我呢。
怎么會(huì)， Doug Lea 大神在 JDK 源碼注釋中給出的就是這樣的例子，這是最根本的功能。你在這個(gè)基礎(chǔ)上，嘗試著優(yōu)化一下?
第二版
小宇：還能怎么優(yōu)化呢?這不已經(jīng)用一個(gè)工具類實(shí)現(xiàn)了異步執(zhí)行了嘛!
閃客：我問你一個(gè)問題，假如有 10000 個(gè)人都調(diào)用這個(gè)工具類提交任務(wù)，那就會(huì)創(chuàng)建 10000 個(gè)線程來執(zhí)行，這肯定不合適吧!能不能控制一下線程的數(shù)量呢?
小宇：這不難，我可以把這個(gè)任務(wù) r 丟到一個(gè) tasks 隊(duì)列中，然后只啟動(dòng)一個(gè)線程，就叫它 Worker 線程吧，不斷從 tasks 隊(duì)列中取任務(wù)，執(zhí)行任務(wù)。這樣無論調(diào)用者調(diào)用多少次，永遠(yuǎn)就只有一個(gè) Worker 線程在運(yùn)行，像這樣。
閃客：太棒了，這個(gè)設(shè)計(jì)有了三個(gè)重大的意義：
1. 控制了線程數(shù)量。
2. 隊(duì)列不但起到了緩沖的作用，還將任務(wù)的提交與執(zhí)行解耦了。
3. 最重要的一點(diǎn)是，解決了每次重復(fù)創(chuàng)建和銷毀線程帶來的系統(tǒng)開銷。
小宇：哇真的么，這么小的改動(dòng)有這么多意義呀。
閃客：那當(dāng)然，不過只有一個(gè)后臺(tái)的工作線程 Worker 會(huì)不會(huì)少了點(diǎn)?還有如果這個(gè) tasks 隊(duì)列滿了怎么辦呢?
第三版
小宇：哦，的確，只有一個(gè)線程在某些場景下是很吃力的，那我把 Worker 線程的數(shù)量增加?
閃客：沒錯(cuò)，Worker 線程的數(shù)量要增加，但是具體數(shù)量要讓使用者決定，調(diào)用時(shí)傳入，就叫核心線程數(shù) corePoolSize 吧。
小宇：好的，那我這樣設(shè)計(jì)。
1. 初始化線程池時(shí)，直接啟動(dòng) corePoolSize 個(gè)工作線程 Worker 先跑著。
2. 這些 Worker 就是死循環(huán)從隊(duì)列里取任務(wù)然后執(zhí)行。
3. execute 方法仍然是直接把任務(wù)放到隊(duì)列，但隊(duì)列滿了之后直接拋棄
閃客：太完美了，獎(jiǎng)勵(lì)你一塊費(fèi)列羅吧。
小宇：哈哈謝謝，那我先吃一會(huì)兒哈。
閃客：好，你邊吃我邊說?，F(xiàn)在我們已經(jīng)實(shí)現(xiàn)了一個(gè)至少不那么丑陋的線程池了，但還有幾處小瑕疵，比如初始化的時(shí)候，就創(chuàng)建了一堆 Worker 線程在那空跑著，假如此時(shí)并沒有異步任務(wù)提交過來執(zhí)行，這就有點(diǎn)浪費(fèi)了。
小宇：哦好像是誒!
閃客：還有，你這隊(duì)列一滿，就直接把新任務(wù)丟棄了，這樣有些粗暴，能不能讓調(diào)用者自己決定該怎么處理呢?
小宇：哎呀，想不到我這么溫柔的妹紙居然寫出了這么粗暴的代碼。
閃客：額，你先把費(fèi)列羅咽下去吧。
第四版
小宇：我吃完了，現(xiàn)在腦子有點(diǎn)不夠用了，得先消化消化食物，要不你幫我分析分析吧。
閃客：好的，現(xiàn)在我們做出如下改進(jìn)。
1. 按需創(chuàng)建Worker：剛初始化線程池時(shí)，不再立刻創(chuàng)建 corePoolSize 個(gè)工作線程，而是等待調(diào)用者不斷提交任務(wù)的過程中，逐漸把工作線程 Worker 創(chuàng)建出來，等數(shù)量達(dá)到 corePoolSize 時(shí)就停止，把任務(wù)直接丟到隊(duì)列里。那就必然要用一個(gè)屬性記錄已經(jīng)創(chuàng)建出來的工作線程數(shù)量，就叫 workCount 吧。
2. 加拒絕策略：實(shí)現(xiàn)上就是增加一個(gè)入?yún)?，類型是一個(gè)接口 RejectedExecutionHandler，由調(diào)用者決定實(shí)現(xiàn)類，以便在任務(wù)提交失敗后執(zhí)行 rejectedExecution 方法。
3. 增加線程工廠：實(shí)現(xiàn)上就是增加一個(gè)入?yún)?，類型是一個(gè)接口 ThreadFactory，增加工作線程時(shí)不再直接 new 線程，而是調(diào)用這個(gè)由調(diào)用者傳入的 ThreadFactory 實(shí)現(xiàn)類的 newThread 方法。
就像下面這樣。
小宇：哇，還是你厲害，這一版應(yīng)該很完美了吧?
閃客：不不不，離完美還差得很遠(yuǎn)，接下來的改進(jìn)，由你來想吧，我這里可以給你一個(gè)提示
彈性思維
第五版
小宇：彈性思維?哈哈閃客你這術(shù)語說的真是越來越不像人話了
閃客：咳咳
小宇：哦，我是說你肯定是指我這個(gè)代碼寫的沒有彈性，對吧?可是彈性是指什么呢?
閃客：簡單說，在這個(gè)場景里，彈性就是在任務(wù)提交比較頻繁，和任務(wù)提交非常不頻繁這兩種情況下，你這個(gè)代碼是否有問題?
小宇：emmm 讓我想想，我這個(gè)線程池，當(dāng)提交任務(wù)的量突增時(shí)，工作線程和隊(duì)列都被占滿了，就只能走拒絕策略，其實(shí)就是被丟棄掉
閃客：是的
小宇：這樣的確是太硬了，誒不過我想了下，調(diào)用方可以通過設(shè)置很大的核心線程數(shù) corePoolSize 來解決這個(gè)問題呀。
閃客：的確是可以，但一般場景下 QPS 高峰期都很短，而為了這個(gè)很短暫的高峰，設(shè)置很大的核心線程數(shù)，簡直太浪費(fèi)資源了，你看上面的圖不覺得眼暈么?
小宇：是呀，那怎么辦呢，太大了也不行，太小了也不行。
閃客：我們可以發(fā)明一個(gè)新的屬性，叫最大線程數(shù) maximumPoolSize。當(dāng)核心線程數(shù)和隊(duì)列都滿了時(shí)，新提交的任務(wù)仍然可以通過創(chuàng)建新的工作線程(叫它非核心線程)，直到工作線程數(shù)達(dá)到 maximumPoolSize 為止，這樣就可以緩解一時(shí)的高峰期了，而用戶也不用設(shè)置過大的核心線程數(shù)。
小宇：哦好像有點(diǎn)感覺了，可是具體怎么操作呢?
閃客：想象力不行呀小宇，那你看下面的演示。
1. 開始的時(shí)候和上一版一樣，當(dāng) workCount < corePoolSize 時(shí)，通過創(chuàng)建新的 Worker 來執(zhí)行任務(wù)。
2. 當(dāng) workCount >= corePoolSize 就停止創(chuàng)建新線程，把任務(wù)直接丟到隊(duì)列里。
3. 但當(dāng)隊(duì)列已滿且仍然 workCount < maximumPoolSize 時(shí)，不再直接走拒絕策略，而是創(chuàng)建非核心線程，直到 workCount = maximumPoolSize，再走拒絕策略。
小宇：哎呀，我怎么沒想到，這樣 corePoolSize 就負(fù)責(zé)平時(shí)大多數(shù)情況所需要的工作線程數(shù)，而 maximumPoolSize 就負(fù)責(zé)在高峰期臨時(shí)擴(kuò)充工作線程數(shù)。
閃客：沒錯(cuò)，高峰時(shí)期的彈性搞定了，那自然就還要考慮低谷時(shí)期。當(dāng)長時(shí)間沒有任務(wù)提交時(shí)，核心線程與非核心線程都一直空跑著，浪費(fèi)資源。我們可以給非核心線程設(shè)定一個(gè)超時(shí)時(shí)間 keepAliveTime，當(dāng)這么長時(shí)間沒能從隊(duì)列里獲取任務(wù)時(shí)，就不再等了，銷毀線程。
小宇：嗯，這回咱們的線程池在 QPS 高峰時(shí)可以臨時(shí)擴(kuò)容，QPS 低谷時(shí)又可以及時(shí)回收線程(非核心線程)而不至于浪費(fèi)資源，真的顯得十分 Q 彈呢。
閃客：是呀是呀。誒不對，怎么又變成我說了，不是說這一版你來思考么?
小宇：我也想啊，但你這一講技術(shù)就自說自話的毛病老是不改，我有啥辦法。
閃客：額抱歉抱歉，那接下來你總結(jié)一下我們的線程池吧
總結(jié)
小宇：嗯好的，首先它的構(gòu)造方法是這個(gè)樣子滴
- public FlashExecutor(
- int corePoolSize,
- int maximumPoolSize,
- long keepAliveTime,
- TimeUnit unit,
- BlockingQueue<Runnable> workQueue,
- ThreadFactory threadFactory,
- RejectedExecutionHandler handler)
- {
- ... // 省略一些參數(shù)校驗(yàn)
- this.corePoolSize = corePoolSize;
- this.maximumPoolSize = maximumPoolSize;
- this.workQueue = workQueue;
- this.keepAliveTime = unit.toNanos(keepAliveTime);
- this.threadFactory = threadFactory;
- this.handler = handler;
- }
這些參數(shù)分別是
int corePoolSize：核心線程數(shù)
int maximumPoolSize：最大線程數(shù)
long keepAliveTime：非核心線程的空閑時(shí)間
TimeUnit unit：空閑時(shí)間的單位
BlockingQueue
ThreadFactory threadFactory：線程工廠
RejectedExecutionHandler handler：拒絕策略
整個(gè)任務(wù)的提交流程是
閃客：不錯(cuò)不錯(cuò)，這可是你自己總結(jié)的喲，現(xiàn)在還用我給你講什么是線程池了么?
小宇：啊天呢，我才發(fā)現(xiàn)這似乎就是我一直弄不清楚的線程池的參數(shù)和原理呢!
閃客：沒錯(cuò)，而且最后一版代碼的構(gòu)造方法，就是 Java 面試?？嫉?ThreadPoolExecutor 最長的那個(gè)構(gòu)造方法，參數(shù)名都沒變。
小宇：哇，太贊了!我都忘了一開始我想干嘛了，嘻嘻。
閃客：哈哈，不知不覺學(xué)到了技術(shù)才爽呢，對吧?晚飯時(shí)間快到了，要不要一塊去吃山西面館呀?
小宇：哦，那家店餐桌的顏色我不太喜歡，下次吧。
閃客：哦好吧。
后記
線程池是面試?？嫉闹R(shí)點(diǎn)，網(wǎng)上很多文章都是直接從它那有 7 個(gè)參數(shù)的構(gòu)造方法講起，強(qiáng)行把各個(gè)參數(shù)的含義說給你聽，讓人云里霧里。
希望讀者讀完本篇文章后，線程池的這些參數(shù)不再是死記硬背，而是像本文中這些動(dòng)圖一樣在你的腦中活靈活現(xiàn)，這樣就能永遠(yuǎn)記住他們啦~
