近期看了一些JVM和併發編程的專欄,結合自身理解,來作一個關於(線程池線程數與(CPU密集型任務和I/O密集型任務)的關係)的總結:css
1.任務類型舉例:算法
1.1: CPU密集型:編程
例如,通常咱們系統的靜態資源,好比js,css等,會存在一個版本號,如 main.js?v0,每當用戶訪問這個資源的時候,會發送一個比對請求到服務端,比對本地靜態文件版本和服務端的文件版本是否一致,不一致則更新.這種任務通常不佔用大量IO,因此後臺服務器能夠快速處理,壓力落在CPU上.服務器
1.2: I/O密集型:併發
比方說近期咱們作的萬科CRM系統,常有大數據量的查詢和批量插入操做,此時的壓力主要在I/O上.大數據
2.線程數與任務類型的關係:線程
2.1:與CPU密集型的關係:生命週期
通常狀況下,CPU核心數 == 最大同時執行線程數.在這種狀況下(設CPU核心數爲n),大量客戶端會發送請求到服務器,可是服務器最多隻能同時執行n個線程.隊列
設線程池工做隊列長度爲m,且m>>n,則此時會致使CPU頻繁切換線程來執行(若是CPU使用的是FCFS,則不會頻繁切換,如使用的是其餘CPU調度算法,如時間片輪轉法,最短期優先,則可能會致使頻繁的線程切換).資源
因此這種狀況下,無需設置過大的線程池工做隊列,(工做隊列長度 = CPU核心數 || CPU核心數+1) 便可.
2.2:與I/O密集型的關係:
1個線程對應1個方法棧,線程的生命週期與方法棧相同.
好比某個線程的方法棧對應的入站順序爲:controller()->service()->DAO(),因爲DAO長時間的I/O操做,致使該線程一直處於工做隊列,但它又不佔用CPU,則此時有1個CPU是處於空閒狀態的.
因此,這種狀況下,應該加大線程池工做隊列的長度(若是CPU調度算法使用的是FCFS,則沒法切換),儘可能不讓CPU空閒下來,提升CPU利用率.
若理解有誤,請指正.