一、需求緣起

Web-Server通常有個配置，***工作線程數(shù)，后端服務一般也有個配置，工作線程池的線程數(shù)量，這個線程數(shù)的配置不同的業(yè)務架構師有不同的經驗值，有些業(yè)務設置為CPU核數(shù)的2倍，有些業(yè)務設置為CPU核數(shù)的8倍，有些業(yè)務設置為CPU核數(shù)的32倍。

“工作線程數(shù)”的設置依據(jù)是什么，到底設置為多少能夠***化CPU性能，是本文要討論的問題。

二、共性認知

在進行進一步深入討論之前，先以提問的方式就一些共性認知達成一致。

問：工作線程數(shù)是不是設置的越大越好?

答：肯定不是的

• 服務器CPU核數(shù)有限，能夠同時并發(fā)的線程數(shù)有限，單核CPU設置10000個工作線程沒有意義
• 線程切換是有開銷的，如果線程切換過于頻繁，反而會使性能降低

問：調用sleep()函數(shù)的時候，線程是否一直占用CPU?

答：不占用，等待時會把CPU讓出來，給其他需要CPU資源的線程使用。

不止sleep()函數(shù)，在進行一些阻塞調用時，例如網絡編程中的：

• 阻塞accept()，等待客戶端連接
• 阻塞recv()，等待下游回包

都不占用CPU資源。

問：單核CPU，設置多線程有意義么，是否能提高并發(fā)性能?

答：即使是單核，使用多線程也是有意義的，大多數(shù)情況也能提高并發(fā)

• 多線程編碼可以讓代碼更加清晰，例如：IO線程收發(fā)包，Worker線程進行任務處理，Timeout線程進行超時檢測
• 如果有一個任務一直占用CPU資源在進行計算，此時增加線程并不能增加并發(fā)，例如以下代碼會一直占用CPU，并使得CPU占用率達到100%：

while(1){ i++; } 

• 通常來說，Worker線程一般不會一直占用CPU進行計算，此時即使CPU是單核，增加Worker線程也能夠提高并發(fā)，因為這個線程在休息的時候，其他的線程可以繼續(xù)工作

三、常見服務線程模型

了解常見的服務線程模型，有助于理解服務并發(fā)的原理，一般來說互聯(lián)網常見的服務線程模型有兩種：

• IO線程與工作現(xiàn)場通過任務隊列解耦
• 純異步

IO線程與工作線程通過隊列解耦類模型

如上圖，大部分Web-Server與服務框架都是使用這樣的一種“IO線程與Worker線程通過隊列解耦”類線程模型：

• 有少數(shù)幾個IO線程監(jiān)聽上游發(fā)過來的請求，并進行收發(fā)包(生產者)
• 有一個或者多個任務隊列，作為IO線程與Worker線程異步解耦的數(shù)據(jù)傳輸通道(臨界資源)
• 有多個工作線程執(zhí)行正真的任務(消費者)

這個線程模型應用很廣，符合大部分場景，這個線程模型的特點是，工作線程內部是同步阻塞執(zhí)行任務的(回想一下tomcat線程中是怎么執(zhí)行Java程序的，dubbo工作線程中是怎么執(zhí)行任務的)，因此可以通過增加Worker線程數(shù)來增加并發(fā)能力，今天要討論的重點是“該模型Worker線程數(shù)設置為多少能達到***的并發(fā)”。

純異步線程模型

沒有阻塞，這種線程模型只需要設置很少的線程數(shù)就能夠做到很高的吞吐量，該模型的缺點是：

• 如果使用單線程模式，難以利用多CPU多核的優(yōu)勢
• 程序員更習慣寫同步代碼，callback的方式對代碼的可讀性有沖擊，對程序員的要求也更高
• 框架更復雜，往往需要server端收發(fā)組件，server端隊列，client端收發(fā)組件，client端隊列，上下文管理組件，有限狀態(tài)機組件，超時管理組件的支持

四、工作線程的工作模式

了解工作線程的工作模式，對量化分析線程數(shù)的設置非常有幫助：

上圖是一個典型的工作線程的處理過程，從開始處理start到結束處理end，該任務的處理共有7個步驟：

• 從工作隊列里拿出任務，進行一些本地初始化計算，例如http協(xié)議分析、參數(shù)解析、參數(shù)校驗等
• 訪問cache拿一些數(shù)據(jù)
• 拿到cache里的數(shù)據(jù)后，再進行一些本地計算，這些計算和業(yè)務邏輯相關
• 通過RPC調用下游service再拿一些數(shù)據(jù)，或者讓下游service去處理一些相關的任務
• RPC調用結束后，再進行一些本地計算，怎么計算和業(yè)務邏輯相關
• 訪問DB進行一些數(shù)據(jù)操作
• 操作完數(shù)據(jù)庫之后做一些收尾工作，同樣這些收尾工作也是本地計算，和業(yè)務邏輯相關

分析整個處理的時間軸，會發(fā)現(xiàn)：

(1) 其中1，3，5，7步驟中(上圖中粉色時間軸)，線程進行本地業(yè)務邏輯計算時需要占用CPU

(2) 而2，4，6步驟中(上圖中橙色時間軸)，訪問cache、service、DB過程中線程處于一個等待結果的狀態(tài)，不需要占用CPU，進一步的分解，這個“等待結果”的時間共分為三部分：

• 請求在網絡上傳輸?shù)较掠蔚腸ache、service、DB
• 下游cache、service、DB進行任務處理
• cache、service、DB將報文在網絡上傳回工作線程

五、量化分析并合理設置工作線程數(shù)

***一起來回答工作線程數(shù)設置為多少合理的問題。

通過上面的分析，Worker線程在執(zhí)行的過程中，有一部計算時間需要占用CPU，另一部分等待時間不需要占用CPU，通過量化分析，例如打日志進行統(tǒng)計，可以統(tǒng)計出整個Worker線程執(zhí)行過程中這兩部分時間的比例，例如：

• 執(zhí)行計算，占用CPU的時間(粉色時間軸)是100ms
• 等待時間，不占用CPU的時間(橙色時間軸)也是100ms

得到的結果是，這個線程計算和等待的時間是1：1，即有50%的時間在計算(占用CPU)，50%的時間在等待(不占用CPU)：

• 假設此時是單核，則設置為2個工作線程就可以把CPU充分利用起來，讓CPU跑到100%
• 假設此時是N核，則設置為2N個工作現(xiàn)場就可以把CPU充分利用起來，讓CPU跑到N*100%

結論：

N核服務器，通過執(zhí)行業(yè)務的單線程分析出本地計算時間為x，等待時間為y，則工作線程數(shù)(線程池線程數(shù))設置為 N*(x+y)/x，能讓CPU的利用率***化。

經驗：

一般來說，非CPU密集型的業(yè)務(加解密、壓縮解壓縮、搜索排序等業(yè)務是CPU密集型的業(yè)務)，瓶頸都在后端數(shù)據(jù)庫訪問或者RPC調用，本地CPU計算的時間很少，所以設置幾十或者幾百個工作線程是能夠提升吞吐量的。

六、總結

• 線程數(shù)不是越多越好
• sleep()不占用CPU
• 單核設置多線程不但能使得代碼清晰，還能提高吞吐量
• 站點和服務最常用的線程模型是“IO線程與工作現(xiàn)場通過任務隊列解耦”，此時設置多工作線程可以提升吞吐量
• N核服務器，通過日志分析出任務執(zhí)行過程中，本地計算時間為x，等待時間為y，則工作線程數(shù)(線程池線程數(shù))設置為 N*(x+y)/x，能讓CPU的利用率***化

【本文為51CTO專欄作者“58沈劍”原創(chuàng)稿件，轉載請聯(lián)系原作者】

戳這里，看該作者更多好文