一、線程池概念

回顧一下,我們最初引入線程的原因:頻繁創(chuàng)建銷毀進程,太慢了,而且開銷很大
同樣的,隨著互聯(lián)網(wǎng)的發(fā)展,隨著我們對于性能要求更進一步~,頻繁創(chuàng)建銷毀線程,開銷有些不能接受了

• 那我們?yōu)榱烁咝У膭?chuàng)建銷毀線程,解決方案有兩個:
• 1.線程池
• 2.協(xié)程(纖程,輕量級線程)

我們本篇文章重點介紹線程池

關(guān)于協(xié)程我們現(xiàn)在只做簡單了解

• 協(xié)程
• Java17左右的時候,才引入到標準庫中,目前在Java圈子還沒有普遍使用
• Go語言更擅長處理"并發(fā)編程"
• 使用協(xié)程,相比于線程性能更高

線程池是一種池化技術(shù),用于預先創(chuàng)建并管理一組線程,避免頻繁創(chuàng)建和銷毀線程的開銷,提高性能和響應速度

(一)什么是線程池

場景:
學校新開了一家快遞店,老板靈機一動,想了個與眾不同的辦法來經(jīng)營店面,店里沒有雇人,而是每次有業(yè)務,就現(xiàn)場找一名同學把快遞送了,然后解雇同學
這就像我們平時處理一個任務,創(chuàng)建一個線程進行處理的模式
很快就發(fā)現(xiàn)了問題,每次招聘+解雇同學的成本還是很高的,所以老板指定了一個指標,業(yè)務人員擴張到3人,但是還會隨著業(yè)務的擴大逐步招人,于是再有業(yè)務,如果公司沒有3個人,就雇1個人去送快遞,否則,只是吧業(yè)務放到一個本本上,等著3個員工空閑的時候去處理,這個就是我們的線程池模式

其實我們早就接觸到了"池"的概念

• 常量池
• 字符串常量,在Java程序最初構(gòu)建的時候,就已經(jīng)準備好,等程序運行的時候,這樣的常量也就加載到內(nèi)存中了,省下了很大構(gòu)造/創(chuàng)建的開銷
• 字符串常量池,線程池,進程池,內(nèi)存池,數(shù)據(jù)庫連接池…
• 就像是一池子備用胎,現(xiàn)在雖然沒有,隨時要拿出來使用

簡單來說線程池:把線程提前創(chuàng)建好,放到一個地方(類似于數(shù)組),需要用的時候,隨時去取,用完了還回到池子中

(二)為什么認為直接創(chuàng)建比在池子中取線程開銷更大

• 操作系統(tǒng)中包含用戶態(tài) 和 內(nèi)核態(tài)
• 一個操作系統(tǒng) = 內(nèi)核 + 配套的應用程序
• 內(nèi)核 中包含操作系統(tǒng)的各種核心功能
• 1)管理硬件設備
• 2)給軟件提供穩(wěn)定的運行環(huán)境
• 一個操作系統(tǒng),內(nèi)核就是一份,一份內(nèi)核要給所有的應用程序提供服務支持

• 如果有一段代碼是應用程序中自行完成,整個執(zhí)行過程是可控的
• 如果有一段代碼,需要進入到內(nèi)核中,由內(nèi)核負責完成一系列工作,這個過程是不可控的,程序員寫的代碼干預不了
• 因此通常認為,可控的過程要比不可控過程更高效~~

從線程池中取現(xiàn)成的線程,純應用程序代碼就可以完成 [可控]
從操作系統(tǒng)創(chuàng)建新線程,就需要操作系統(tǒng)內(nèi)核配合完成 [不可控]
使用線程池,就可以省下應用程序切換到內(nèi)核中運行這樣的開銷

二、標準庫中的線程池 ThreadPoolExecutor

• 線程池的核心方法,submit(Runnable)
• 通過Runnable描述一段要執(zhí)行的任務
• 通過submit任務放到線程池中
• 此時線程池里的線程就會執(zhí)行這樣的任務

(一)構(gòu)造方法

(二)七個參數(shù)含義(后四個重點掌握)

Java的線程池,里面包含幾個線程,是可以動態(tài)調(diào)整的,任務多的時候,自動擴容成更多的線程,任務少的時候 ,把額外的線程干掉,節(jié)省資源

• 1.int corePoolSize 核心線程數(shù)
  線程池中至少有多少個線程,線程池一創(chuàng)建,這些線程也要隨之創(chuàng)建,直到整個線程池銷毀,這些線程才會銷毀

• 2.int maximumPoolSize 最大線程數(shù) = 核心線程+非核心線程(自適應)
  若任務并不繁忙就會銷毀,繁忙就再創(chuàng)建,線程也不是越多越好,畢竟線程太多會搶占資源

• 3.long keepAliveTime 非核心線程允許空閑的最大時間
  不能這個線程一空閑下來,就直接把它銷毀,因為可能下一秒就需要他干活啦,我們?yōu)樗O置一個最大的摸魚時間~~

• 4.TimeUnit unit 是一個枚舉類型的參數(shù)，作為keepAliveTime 的時間單位，是秒，分鐘或者其他值
  

• 5.BlockingQueue workQueue : 工作隊列

• 我們可以選擇使用數(shù)組/鏈表 指定capacity 指定是否要帶有優(yōu)先級/比較規(guī)則

• 泛型為Runnable ,說明阻塞隊列中的元素是一個個Runnable任務

• 每次通過調(diào)用 submit() 方法,submit就會將任務添加到隊列(阻塞隊列)

• 因為需要以阻塞隊列為基礎,進行數(shù)據(jù)交互,所以工作隊列的類型為BlockingQueue

線程池本質(zhì)上也是生產(chǎn)者消費者模型,調(diào)用submit就是在生產(chǎn)任務,線程池里的線程就是在消費任務

• 6. ThreadFactory threadFactory : 線程工廠 統(tǒng)一的構(gòu)造并初始化線程
  利用工廠模式來彌補構(gòu)造方法的缺陷(無法構(gòu)成重載)

(三)工廠模式

• 是一種創(chuàng)建型的設計模式,提供了一種封裝對象創(chuàng)建過程的方法
• 工廠模式通過靜態(tài)方法,將對象的創(chuàng)建(實例化 & 初始化) 將創(chuàng)建對象的過程封裝好,彌補構(gòu)造方法的缺陷
• 有助于降低代碼的耦合度,提高可維護性和可擴展性

1) 典型案例

• 這是 C++ 和 Java共有的一個問題
• 構(gòu)造方法的名字是固定的,想要提供不同的版本,需要通過重載來實現(xiàn),但是像上述情況就無法構(gòu)成重載,需要借助工廠模式實現(xiàn)

2) 使用工廠模式

• 其中 用來構(gòu)造對象的靜態(tài)方法(makePointByXY & makePointByRA) 稱為工廠方法
• 提供工廠方法的類(PointFactory) 稱為工廠類

通過單獨的類(PointFactory)提供工廠方法(makePointByXY & makePointByRA),和構(gòu)造對象的類(Point)分開,這是更科學的工廠設計模式

工廠方法的核心:通過靜態(tài)方法,把構(gòu)造對象new的過程,各種屬性初始化的過程,封裝起來,提供多組靜態(tài)方法,實現(xiàn)不同情況的構(gòu)造

我們繼續(xù)回到第六個參數(shù)ThreadFactory threadFactory : 線程工廠

• 此外如果想讓線程池中的線程具有其他的特性,或者想去干預這些線程的其他功能,都可以手動實現(xiàn) ThreadFactory接口,重寫newThread()方法

class SimpleThreadFactory implements ThreadFctory{public Thread newThread(Runnable r){return new Thread(r);}
}

• 標準庫通過這個方法,幫我們設置好線程池中基本的線程屬性

• 7.RejectedExecutionHandler handler : 拒絕策略
  整個線程池七個參數(shù)中,最重要,最復雜的

(四)拒絕策略

RejectedExecutionHandler handler

• 1) AbortPolicy --異常,線程池可能無法繼續(xù)工作

• 當任務隊列滿且沒有線程空閑,此時添加任務會直接拋出RejectedExecutionException異常,這也是默認的拒絕策略

• 非但新的任務干不了,甚至之前舊的任務也干不了了~

• 2) CallerRunsPolicy --讓調(diào)用者自己干

• 當任務隊列滿且沒有線程空閑,此時添加任務由調(diào)用者線程即調(diào)用submit的線程來執(zhí)行該任務

• 也就是說submit整個方法里的代碼,都是在這個線程中執(zhí)行的

• submit方法里,暗藏玄機~

• 判定當前隊列是否滿,判定當前拒絕策略是否為CallerRunsPlicy ,如果兩個判斷都為true

• submit內(nèi)部就會直接調(diào)用 Runnable,run()

偽代碼:

void submit(Runnable runnable){if(隊列滿了 && 拒絕策略為CallerRunsPlicy){runnable.run();return ;}queue.put(runnable);//若不->線程池里的一組線程來執(zhí)行任務return ;
}

一個進程中會有很多個線程,假設線程池中已經(jīng)有4個線程(a,b,c,d),現(xiàn)在來了一個新的線程X,調(diào)用submit方法
此時X調(diào)用submit,就是執(zhí)行上述的偽代碼邏輯,X就是調(diào)用者線程

• 3) DiscardOldestPolicy --丟棄最老的任務,干當前給的新任務

• 當任務隊列滿且沒有線程空閑,會刪除最早的任務,處理最新的任務

• 4) DiscardPolicy --丟掉當前的新任務

• 直接丟棄當前給的這個新任務,不會執(zhí)行任何操作,也不會拋出異常

• 自定義拒絕策略
  

為什么使用線程池而不使用生產(chǎn)者消費者模型

在了解了拒絕策略后,再做一個掃盲,我們前面說,線程池的本質(zhì)就是生產(chǎn)者消費者模型,那么為什么我們不直接使用生產(chǎn)者消費者模型

• submit把任務添加到任務隊列中,這個任務隊列就是阻塞隊列
• 隊列滿了,再添加,就會阻塞,但是我們一般不希望程序阻塞太多
• 對于線程池來說,入隊列時發(fā)現(xiàn)隊列滿了,不會真的觸發(fā)"入隊列操作",不是真的阻塞,而是執(zhí)行拒絕策略的相關(guān)代碼
• 如果業(yè)務邏輯中的線程調(diào)用submit就阻塞,就會使這個線程無法干別的事情了,明顯不是一個好的選擇
• 線程響應用戶的請求阻塞了,用戶遲遲拿不到響應,直觀上的現(xiàn)象是"卡了",其實是失敗了,與其告訴我"卡了",不如直接告訴我"失敗了"

線程池最大的好處就是減少每次啟動,銷毀線程的損耗