目錄
- 背景介紹
- 線程池的基本工作原理
- 線程池高并發場景下問題剖析
- 線程池高并發場景下性能優化
- 總結
背景介紹
大家好，今天給大家講一個比較偏硬核技術類的知識，就是 Java 線程池在生産項目中的高并發優化。
可能很多兄弟都聽說過 Java 線程池的理論原理，知道他是怎麼運作的，但是從來沒在項目裡玩兒過 Java 線程池，更沒在高并發環境下玩兒過 Java 線程池的優化，是以今天我們來一起探讨一下這個 Java 線程池在生産項目中的高并發優化！
線程池的基本工作原理
既然要聊線程池，那最起碼大家得大概知道一點兒 Java 線程池的基本工作原理，如果要把線程池原理講清楚，甚至剖析到 JDK 線程池的源碼層面，那可能得單獨開一篇文章來寫，這不是我們這次的主題，是以我們就把線程池最簡單的原理給大家講一下先。
線程池，簡單來說，就是他有一個池子，裡面放了一堆的線程，這些線程一般是不會銷毀的，他們會一直存在，然後你可以不停的給線程池送出任務。
線程池會拿線程出來執行你的任務，任務執行完了以後，線程不會終止，他就繼續線上程池裡待命就可以了。
我們看下圖 1 所示：
但是這個時候會有一個關鍵的問題，那就是線程池裡的線程數量通常是有限制的。
注意，這裡說的是通常，因為 Java 線程池的真正原理來說，其實通過定制化手段，可以讓 Java 線程池有各種各樣不同的表現，我們這裡就是說最基礎的一種情況，那就是線程池裡的線程數量是固定的，而且是有限的。
所有如果說你要是一下子送出了太多的任務給線程池，然後此時所有的線程都在忙着運作自己的任務呢，這個時候你要是再想送出新的任務，你覺得會如何？任務能送出進去嗎？
看下圖 2 所示：
那當然沒法送出進去了，但是此時難道線程池隻能拒絕你嗎？那倒也不是，線程池為了應對這種情況，通常會設定一個隊列讓你送出任務，讓你的任務在隊列裡等待一段時間，等有線程運作完了自己的任務，空閑出來了，再來運作這個隊列裡的任務。
注意，這也是通常情況，因為 Java 線程池通過定制其實可以有别的表現，隻不過通常線程池我們會這麼設定而已。
如下圖 3 所示：
線程池高并發場景下問題剖析
好那麼接着問題來了，上面這個就是最最基礎的 Java 線程池的原理和用法，但是真正投入到一個生産項目裡以後，他會遇到什麼樣的問題呢？
首先最大的一個問題，就是送出到線程池裡的任務，可能都是要執行各種網絡 IO 的任務。
比如說，RPC 調用其他的服務，或者說是背景處理 DB 裡大量的資料，是以很可能會導緻線程運作完一個任務要耗費很長時間，從幾百毫秒到幾秒，甚至幾十秒，都有這種可能。
如下圖 4 所示：
第二個問題，大家注意到上圖沒有，就是有的任務是 RPC 調用，可能僅僅是耗費幾百 ms，有的任務是大量資料操作，可能會耗費幾十秒。
是以說，其實一個公共的線程池裡，運作了各種不同的任務，這就導緻了線程池裡的一個線程什麼時候能執行完一個任務，那是不确定的，因為任務有可能是 RPC 調用，也可能是大資料量處理。
第三個問題，可能有一些任務是在一個 Http 請求裡的，原本可能是在一個 Http 請求處理過程中，會依次處理多個耗時的任務。
現在為了優化性能，需要送出多個任務到線程池裡，利用多個線程并發執行多個任務，提升本次請求的性能，這個 Http 請求需要等待這多個并發運作的任務都執行結束了，才會給使用者傳回響應。
如下圖 5 所示：
是以說，終極大問題來了，這種在生産項目裡跑的線程池，因為提供給了各種不同的任務來共用，比如說定時 RPC 調用，定時大資料量處理，前台 Http 請求多任務并發。
是以在生産環境繁忙期的時候，可能有如下場景：線程池此時正在運作多個定時 RPC 調用、定時大資料量處理的任務，這些任務又特别的耗時，導緻很多線程都是忙碌狀态，少數線程是空閑狀态。
然後這個時候，系統剛好面向 C 端使用者提供的接口有高并發通路的場景，大量 Http 請求過來，每個請求都要送出多個任務給線程池并發運作，導緻線程池的少數空閑線程快速的跑滿，然後接着大量的任務進入了線程池的隊列開始排隊等待。
如下圖 6 所示：
這個時候必然會導緻大量的 Http 請求出現 hang 死的問題，因為很多 Http 請求的任務都線上程池裡排隊等待，他們沒法運作，Http 請求也就沒法傳回響應，給使用者的感覺就是點選 APP/網頁一類的前端，點來點去沒反應，系統出現卡頓問題！
如下圖 7 所示：
線程池高并發場景下性能優化
針對這種生産環境的問題，我們需要做的第一個最大的改善，就是把各種不同的任務從一個線程池裡分離出來，讓他們互相之間不要影響。
也就是說，定時 RPC 任務就放一個線程池裡去，定時 DB 大量資料處理任務放另外一個線程池裡去，然後 Http 請求多任務并發處理放一個獨立的線程池，大家各自用自己的線程池和資源，互相之間不影響。
如下圖 8 所示：
如上圖所做的話，我們有一個專門處理 Http 請求的線程池，這壓力一下子就下來了，因為 Http 請求的任務通常耗時都在幾十 ms 到一百 ms 級，整體速度很快，線程池裡沒有定時 RPC 和定時 DB 通路這種耗時任務進來搗亂了。
是以 Http 請求的專有線程池可以輕松+愉快的快速的處理所有 Http 請求的任務，即使是在高并發場景下，可以通過線程池增加線程資源來合理抗下高并發壓力。
另外就是對線上系統生産環境的線程池任務運作，我們通常會在公司裡或者項目内研發統一的線程池監控架構。
所有的線程池任務都需要封裝到一個線程池監控架構提供的 Class 裡，然後通過這個 Class 來實作任務的排隊等待與運作耗時的兩個次元的監控資料統計。
如下面的代碼所示：
// 線程任務包裝類，用了裝飾設計模式
public class RunnableWrapper implements Runnable {
// 實際要執行的線程任務
private Runnable task;
// 線程任務被建立出來的時間
private long createTime;
// 線程任務被線程池運作的開始時間
private long startTime;
// 線程任務被線程池運作的結束時間
private long endTime;
// 當這個任務被建立出來的時候，就會設定他的建立時間
// 但是接下來有可能這個任務送出到線程池後，會進入線程池的隊列排隊
public RunnableWrapper(Runnable task) {
this.task = task;
this.createTime = new Date().getTime();
}
// 當任務線上程池排隊的時候，這個run方法是不會被運作的
// 但是當任務結束了排隊，得到線程池運作機會的時候，這個方法會被調用
// 此時就可以設定線程任務的開始運作時間
public void run() {
this.startTime = new Date().getTime();
// 此處可以通過調用監控系統的API，實作監控名額上報
// 用線程任務的startTime-createTime，其實就是任務排隊時間
// monitor.report("threadName", "queueWaitTime", startTime-createTime);
// 接着可以調用包裝的實際任務的run方法
task.run();
// 任務運作完畢以後，會設定任務運作結束的時間
this.endTIme = new Date().getTime();
// 此處可以通過調用監控系統的API，實作監控名額上報
// 用線程任務的endTime - startTime，其實就是任務運作時間
// monitor.report("threadName", "taskRunTime", endTime - startTime);
}
} 大家通過上面的代碼可以清晰的看到，隻要我們所有送出到線程池的任務，都用一個架構統一封裝的 RunnableWrapper 類，基于裝飾模式來進行包裝。
此時就可以得到線程任務的建立時間、開始時間、結束時間，接着就可以計算出這個任務的排隊耗時、運作耗時，通過監控系統進行上報。
此時我們通過在監控系統裡配置告警條件，就可以實作不同線程池的每個任務的耗時名額上報，同時如果有某個線程池的某個線程排隊耗時或者運作耗時超過了我們配置的門檻值，就會自動告警。
如下圖 9 所示：
總結
好了，今天這篇文章到此為止，把我們的線程池在生産項目裡的生産問題和高并發如何優化，以及生産環境下的監控方案，都告訴大家了。
希望大家學以緻用，以後在項目裡用線程池的時候，能夠靈活運用咱們文章裡學到的知識點。
------------- END -------------
另外推薦儒猿課堂的1元系列課程給您，歡迎加入一起學習~
網際網路Java工程師面試突擊課（1元專享）：
https://tod.h5.xeknow.com/s/3o8O0w
SpringCloudAlibaba零基礎入門到項目實戰（1元專享）：
https://tod.h5.xeknow.com/s/1NRrqb
億級流量下的電商詳情頁系統實戰項目（1元專享）：
https://tod.h5.xeknow.com/s/xItYJ
Kafka消息中間件核心源碼精講（1元專享）：
https://tod.h5.xeknow.com/s/1T0B9m
12個實戰案例帶你玩轉Java并發程式設計（1元專享）：
https://tod.h5.xeknow.com/s/2nTSHI
Elasticsearch零基礎入門到精通（1元專享）：
https://tod.h5.xeknow.com/s/40xOVv
基于Java手寫分布式中間件系統實戰（1元專享）：
https://tod.h5.xeknow.com/s/1MUj1A
基于ShardingSphere的分庫分表實戰課（1元專享）：
https://tod.h5.xeknow.com/s/3o6jC