服務器性能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、內存、硬盤讀寫速度、網絡狀況等）來不斷嘗試以尋求一個符合實際的合理值。