線程池的工作原理(線程池的工作原理是什么)

線程池的自我介紹

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

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

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

corePoolSize

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

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

publicinterfaceExecutor{voidexecute(Runnablecommand);}

由于我誕生后還沒有執行過任務,核心線程一直為 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。

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

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