線程池的工作原理是什么

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

線程池的自我介紹

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

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

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

corePoolSize

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

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

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

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

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

過了一段時間，第一個核心線程已經(jīng)執(zhí)行完任務，空閑出來了，此時任務又來了。。。

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

經(jīng)過上面的一番操作，核心線程數(shù)來到了最開始設置的數(shù)量 3 了。

workQueue

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

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

畫外音：線程等待是指調用 LockSupport.park 將線程從運行態(tài)變?yōu)樽枞麘B(tài)，此時線程就不占用 CPU 資源了

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

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

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

maximumPoolSize

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

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

RejectedExecutionHandler

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

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

keepAliveTime

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

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

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

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