線程池的工作原理是什么

這篇文章主要講解了“線程池的工作原理是什么”，文中的講解內容簡單清晰，易于學習與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學習“線程池的工作原理是什么”吧！

線程池的自我介紹

我是一個線程池(ThreadPoolExecutor)，我的主要工作是管理在我這的多個線程(Thread)，讓他們能并發地執行多個任務的同時，又不會造成很大的的系統開銷，有人不明白，創建線程有啥開銷呢，不是只要  new 一個 Thread 出來讓它跑就行了嗎，這里我要簡單解釋下：

1. 其實 Java 中的線程模型是基于操作系統原生線程模型實現的，也就是說 Java  中的線程其實是基于內核線程實現的，線程的創建，析構與同步都需要進行系統調用，而系統調用需要在用戶態與內核中來回切換，代價相對較高，線程的生命周期包括「線程創建時間」,「線程執行任務時間」,「線程銷毀時間」，創建和銷毀都需要導致系統調用。

2. 每個 Thread 都需要有一個內核線程的支持，也就意味著每個 Thread 都需要消耗一定的內核資源(如內核線程的棧空間)，因為能創建的 Thread  是有限的，默認一個線程的線程棧大小是 1 M，如果每來一個任務就創建線程的話，1024 個任務就光創建線程就占用了 1 G 內存，很容易就系統崩潰了。

corePoolSize

所以我的主要作用就是減少線程的創建時間和銷毀時間，線程創建后不讓它馬上銷毀，而是常駐在我這，隨叫隨到，我把這些常駐的線程叫做核心線程，核心線程數也不宜過多，所以我指定了它們的數量(corePoolSize)，假定為  3 吧。

「線程池，這是我的一個任務，幫我執行一下吧」，主線程丟給我任務后立馬返回，于是我趕緊調用 execute  方法來處理丟給我的這個任務(Runnable)

public interface Executor {     void execute(Runnable command); }

由于我誕生后還沒有執行過任務，核心線程一直為 0，于是在這個方法里我創建了一個線程作為核心線程。

「線程池，任務又來了，幫我執行一下吧」，又來任務了!于是我再次調用了 execute，又創建了一個核心線程，此時核心線程數為 2。

過了一段時間，第一個核心線程已經執行完任務，空閑出來了，此時任務又來了。。。

「線程池，這是我的一個任務，幫我執行一下吧」主線程摞下一句話后又走了，此時是 1  個核心線程在忙碌，一個核心線程空閑，可能很多人誤以為這里既然有一個核心線程在空閑，那就把任務交給這個線程處理即可，不用再創建核心線程了，但實際上只要當前核心線程數少于當初設置的  corePoolSize，不管當前核心線程是否空閑，我依然會再創建一個核心線程，主要是為了保證核心線程盡快達到我們設置的數量，這樣如果之后有很多任務涌進來，這些已創建好的核心線程就可以馬上準備好處理這些任務了，不需要再經過創建線程這種耗時的操作了。

經過上面的一番操作，核心線程數來到了最開始設置的數量 3 了。

workQueue

「線程池，任務又來了，幫我執行一下吧」，熟悉的聲音又來了，此時核心線程已經達到了我們設置的數量 3  個了，再創建線程當然可以，但又要造成一個系統調用，開銷比較大，其實核心線程可能經過很短的時間又能馬上空閑出來了，不如把任務放到放到一個隊列里，讓這些核心線程自己去取。

聰明的你一定發現了，這就是典型的生產者-消費者模型，線程池中的線程只要不斷循環去 workQueue 隊列獲取任務即可，為了避免 workQueue  為空線程一直輪詢導致的 CPU 資源被占用的問題，這里的 workQueue 采用了阻塞隊列，所謂阻塞是指，如果 workQueue  為空，則獲取元素的線程會等待隊列變為非空，一旦有新的任務入隊列，會喚醒等待中的線程。

畫外音：線程等待是指調用 LockSupport.park 將線程從運行態變為阻塞態，此時線程就不占用 CPU 資源了

可是好景不長， JVM 老大向我反饋出現 OOM  問題了，一看問題我就明白了，原來是哪個新手程序員在創建我的時候，聲明使用了無界隊列，導致核心線程無法及時處理任務，而任務又源源不斷地添加進了 workQueue  中(即生產任務速度遠大于消費任務速度)，導致 workQueue 越來越大，最終產生了 OOM!

解決方式很簡單，使用有界隊列即可，這樣當 workQueue 滿時就無法添加任務了，不會導致 workQueue 無限增大導致 OOM。

畫外音：所謂有界隊列是指設定了固定大小的隊列，當隊列里的元素超過這個大小后就再也不能往這個隊列里塞任務了，而無界隊列由于沒有設置固定大小  ，可以直接入隊，直到溢出，容易造成 OOM，所以創建線程池時應該盡量使用有界隊列

maximumPoolSize

將 workQueue 改用有界隊列后，再也沒出現過 OOM  了，不過由于主線程又源源不斷地丟了一些耗時的任務過來，核心線程依然處理不過來，workQueue 很快又滿了，這時我想起了另一個參數  maximumPoolSize，這個參數定義了我能創建的最大線程數，當其它線程要往隊列塞任務，但發現 workQueue 滿時，由于當前在我這的線程還未到達  maximumPoolSize(假設起初指定為 5)，所以我又創建了線程來處理這個任務。

畫外音: 在 workQueue 已滿的條件下，如果當前線程池的線程數量 >= corePoolSize 且 <=  maximumPoolSize，后續如果一直有其它線程丟任務進來，會一直創建線程，直到 maximumPoolSize。

RejectedExecutionHandler

某天，往我這丟任務的某個線程反饋收到異常了，我一看，我靠，workQueue 滿了，線程數也達到了  maximumPoolSize，但此時依然有任務不斷往 workQueue 中插，但這種情況下已經超出了我的處理能力了，只好執行默認的拒絕策略，拋出  RejectedExecutionException 異常讓其他線程(往我這丟任務的線程)自己處理。

畫外音：線程池提供了  AbortPolicy，DiscardPolicy，DiscardOldestPolicy，CallerRunsPolicy，自定義這五種拒絕策略，默認是  AbortPolicy

keepAliveTime

在線程們的努力之下，workQueue  隊列中的任務很快被清空了，很長一段時間都沒有任務進來了，線程們很快就無事可做，放著又占用資源，該怎么處理呢?此時我這有核心線程 3(corePoolSize =  3)， 額外線程 2 (maximumPoolSize 為 5)，

我是這么處理的，如果當前線程總數超過了 corePoolSize，在 keepAliveTime  這個時間內，如果池子里的線程一直空閑，就把這個線程給干掉，哪個線程空閑時間先到達 keepAliveTime，就干掉哪個，直到線程數減少到  corePoolSize。

畫外音：線程池里沒有核心線程和額外線程之分，只是為了講述方便人為劃分了一下，但其實線程池里的線程都是平等的，任何一個線程都可以被干掉

感謝各位的閱讀，以上就是“線程池的工作原理是什么”的內容了，經過本文的學習后，相信大家對線程池的工作原理是什么這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關知識點的文章，歡迎關注！