點擊上方"java全棧技術"關注，每天學習一個java知識點
如何合理地估算線程池大小？
這個問題雖然看起來很小，卻並不那麼容易回答。大家如果有更好的方法歡迎賜教，先來一個天真的估算方法：假設要求一個系統的TPS（Transaction Per Second或者Task Per Second）至少為20，然後假設每個Transaction由一個線程完成，繼續假設平均每個線程處理一個Transaction的時間為4s。那麼問題轉化為：
如何設計線程池大小，使得可以在1s內處理完20個Transaction？
計算過程很簡單，每個線程的處理能力為0.25TPS，那麼要達到20TPS，顯然需要20/0.25=80個線程。
很顯然這個估算方法很天真，因為它沒有考慮到CPU數目。一般服務器的CPU核數為16或者32，如果有80個線程，那麼肯定會帶來太多不必要的線程上下文切換開銷。
再來第二種簡單的但不知是否可行的方法（N為CPU總核數）：
- 如果是CPU密集型應用，則線程池大小設置為N+1
- 如果是IO密集型應用，則線程池大小設置為2N+1
如果一臺服務器上只部署這一個應用並且只有這一個線程池，那麼這種估算或許合理，具體還需自行測試驗證。
接下來在這個文檔：服務器性能IO優化 中發現一個估算公式：
最佳線程數目 = （（線程等待時間+線程CPU時間）/線程CPU時間 ）* CPU數目
比如平均每個線程CPU運行時間為0.5s，而線程等待時間（非CPU運行時間，比如IO）為1.5s，CPU核心數為8，那麼根據上面這個公式估算得到：((0.5+1.5)/0.5)*8=32。這個公式進一步轉化為：
最佳線程數目 = （線程等待時間與線程CPU時間之比 + 1）* CPU數目
可以得出一個結論：
線程等待時間所佔比例越高，需要越多線程。線程CPU時間所佔比例越高，需要越少線程。
上一種估算方法也和這個結論相合。
一個系統最快的部分是CPU，所以決定一個系統吞吐量上限的是CPU。增強CPU處理能力，可以提高系統吞吐量上限。但根據短板效應，真實的系統吞吐量並不能單純根據CPU來計算。那要提高系統吞吐量，就需要從“系統短板”（比如網絡延遲、IO）著手：
- 儘量提高短板操作的並行化比率，比如多線程下載技術
- 增強短板能力，比如用NIO替代IO
第一條可以聯繫到Amdahl定律，這條定律定義了串行系統並行化後的加速比計算公式：
加速比=優化前系統耗時 / 優化後系統耗時
加速比越大，表明系統並行化的優化效果越好。Addahl定律還給出了系統並行度、CPU數目和加速比的關係，加速比為Speedup，系統串行化比率（指串行執行代碼所佔比率）為F，CPU數目為N：
Speedup <= 1 / (F + (1-F)/N)
當N足夠大時，串行化比率F越小，加速比Speedup越大。
寫到這裡，我突然冒出一個問題。
是否使用線程池就一定比使用單線程高效呢？
答案是否定的，比如Redis就是單線程的，但它卻非常高效，基本操作都能達到十萬量級/s。從線程這個角度來看，部分原因在於：
- 多線程帶來線程上下文切換開銷，單線程就沒有這種開銷
- 鎖
當然“Redis很快”更本質的原因在於：Redis基本都是內存操作，這種情況下單線程可以很高效地利用CPU。而多線程適用場景一般是：存在相當比例的IO和網絡操作。
所以即使有上面的簡單估算方法，也許看似合理，但實際上也未必合理，都需要結合系統真實情況（比如是IO密集型或者是CPU密集型或者是純內存操作）和硬件環境（CPU、內存、硬盤讀寫速度、網絡狀況等）來不斷嘗試達到一個符合實際的合理估算值。
最後來一個“Dark Magic”估算方法（因為我暫時還沒有搞懂它的原理），使用下面的類：
然後自己繼承這個抽象類並實現它的三個抽象方法，比如下面是我寫的一個示例（任務是請求網絡數據），其中我指定期望CPU利用率為1.0（即100%），任務隊列總大小不超過100,000字節：
得到的輸出如下：
推薦的任務隊列大小為2500，線程數為256，有點出乎意料之外。我可以如下構造一個線程池：
閱讀更多 java全棧技術 的文章
