多執行緒，到底該設定多少個執行緒？

「不好了，線上伺服器超時嚴重，請求非常慢，好像報連線數too many了，怎麼辦？「小夥伴們在反饋。一般我們的技術老大的處理方式，把連線數和執行緒池調大點，重啟，再觀察。

往往這個方式是應急措施，治標不治本，因為不知道問題的原因。

有個嚴重誤區，以為執行緒池設定太小了，調大點請求就會快了。

今天就帶著小夥伴們溝通一下，執行緒池的大小應該如何合理的設定其大小？

如果有兩個任務需要處理，乙個任務a，乙個任務b

方案一：乙個執行緒執行任務a和b，a執行完後，執行b

方案二：兩個執行緒a和b去執行任務a 和 b，同時進行

哪個方案會快點？應該很多人會回答，肯定是方案二啊，多執行緒並行去處理任務a和b，肯定快啊。是這樣嗎？回答這個問題之前，先帶著大家去回顧梳理一下。

執行緒的執行，是由cpu進行排程的，乙個cpu在同一時刻只會執行乙個執行緒，我們看上去的執行緒a 和執行緒b併發執行。

為了讓使用者感覺這些任務正在同時進行，作業系統利用了時間片輪轉的方式，cpu給每個任務都服務一定的時間，然後把當前任務的狀態儲存下來，在載入下一任務的狀態後，繼續服務下一任務。任務的狀態儲存及再載入，這段過程就叫做上下文切換。

上下文切換過程是需要時間的；現在我們來看一下上面的問題，小夥伴們再看一下是哪個方案快呢？是不是有些小夥伴們會說方案一，因為不需要執行緒切換；方案二需要來回切換這兩個執行緒，耗時會多點。

小夥伴們心中此時是不是會有疑惑，那為什麼會有多執行緒？先不急，再往下看。

小夥伴想想在我們真實業務中，我們是什麼流程？

上圖的流程：

1、先發起網路請求

2、web伺服器解析請求

3、請求後端的資料庫獲取資料

4、獲取資料後，進行處理

5、把處理結果放回給使用者

這個是我們處理業務的時候，常規的請求流程；我們看一下整個過程涉及到什麼計算機處理。

1、網路請求----->網路io

2、解析請求----->cpu

3、請求資料庫----->網路io

4、mysql查詢資料----->磁碟io

5、mysql返回資料----->網路io

6、資料處理----->cpu

7、返回資料給使用者----->網路io

講到這裡，小夥伴們是不是感覺又不亂了，在真實業務中我們不單單會涉及cpu計算，還有網路io和磁碟io處理，這些處理是非常耗時的。如果乙個執行緒整個流程是上圖的流程，真正涉及到cpu的只有2個節點，其他的節點都是io處理，那麼執行緒在做io處理的時候，cpu就空閒出來了，cpu的利用率就不高。

小夥伴們現在知道多執行緒的用處了吧，對，就是為了提公升cpu利用率。

衡量系統效能如何，主要指標系統的（qps/tps）

qps/tps = 併發數/響應時間

上面公式代表併發數越大，qps就越大；所以很多人就會以為調大執行緒池，併發數就會大，也會提公升qps，所以才會出現一開始前言所說的，大多數人的誤區。

其實qps還跟響應時間成反比，響應時間越大，qps就會越小。

雖然併發數調大了，就會提公升qps，但執行緒數也會影響響應時間，因為上面我們也提到了上下文切換的問題，那怎麼設定執行緒數的呢？

那我們如何分配執行緒？我們提供乙個公式：

最佳執行緒數目 = （（執行緒等待時間+執行緒cpu時間）/執行緒cpu時間）* cpu數目

備註這個公式也是前輩們分享的，當然之前看了**前台系統優化實踐的文章，和上面的公式很類似，不過在cpu數目那邊，他們更細化了，上面的公式只是參考。不過不管什麼公式，最終還是在生產環境中執行後，再優化調整。

我們繼續上面的任務，我們的伺服器cpu核數為4核，乙個任務執行緒cpu耗時為20ms，執行緒等待（網路io、磁碟io）耗時80ms，那最佳執行緒數目：( 80 + 20 )/20 * 4 = 20。也就是設定20個執行緒數最佳。

從這個公式上面我們就得出，執行緒的等待時間越大，執行緒數就要設定越大，這個正好符合我們上面的分析，可提公升cpu利用率。那從另乙個角度上面說，執行緒數設定多大，是根據我們自身的業務的，需要自己去壓力測試，設定乙個合理的數值。

那我們小夥伴們會問，因為很多業務集中到乙個執行緒池中，不像上面的案例比較簡單，事實上業務太多，怎麼設定呢？這個就是要去壓力測試去調整。不過我們的前輩已經幫我們總結了乙個基礎的值（最終還是要看運**況自行調整）

1、cpu密集型：操作記憶體處理的業務，一般執行緒數設定為：cpu核數 + 1 或者 cpu核數*2。核數為4的話，一般設定 5 或 8

2、io密集型：檔案操作，網路操作，資料庫操作，一般執行緒設定為：cpu核數 / (1-0.9)，核數為4的話，一般設定 40

今天介紹了執行緒數大小的設定，一些小夥伴們的誤區。講到這裡我們小夥伴們是不是對執行緒有了更新的理解，不像之前那麼粗暴，應該要去分析為什麼這麼慢，系統的瓶頸出現在什麼地方，減少瓶頸的耗時。