面試問我，創建多少個線程合適？我該怎么說

| 如果好看，請給個贊

• 你有一個思想，我有一個思想，我們交換后，一個人就有兩個思想

• If you can NOT explain it simply, you do NOT understand it well enough

現陸續將Demo代碼和技術文章整理在一起 Github實踐精選 ，方便大家閱讀查看，本文同樣收錄在此，覺得不錯，還請Star

為什么要使用多線程？

防止並發編程出錯最好的辦法就是不寫並發程序

既然多線程編程容易出錯，為什么它還經久不衰呢？

A：那還用說，肯定在某些方面有特長唄，比如你知道的【它很快，非常快】

我也很贊同這個答案，但說的不夠具體

並發編程適用於什么場景？

如果問你選擇多線程的原因就是一個【快】字，面試也就不會出那么多幺蛾子了。你有沒有問過你自己

1. 並發編程在所有場景下都是快的嗎？
2. 知道它很快，何為快？怎樣度量？

想知道這兩個問題的答案，我們需要一個從【定性】到【定量】的分析過程

使用多線程就是在正確的場景下通過設置正確個數的線程來最大化程序的運行速度（我感覺你還是啥也沒說）

將這句話翻譯到硬件級別就是要充分的利用 CPU 和 I/O 的利用率

兩個正確得到保證，也就能達到最大化利用 CPU 和 I/O的目的了。最關鍵是，如何做到兩個【正確】？

在聊具體場景的時候，我們必須要拿出我們的專業性來。送你兩個名詞 buff 加成

• CPU 密集型程序
• I/O 密集型程序

CPU 密集型程序

一個完整請求，I/O操作可以在很短時間內完成， CPU還有很多運算要處理，也就是說 CPU 計算的比例占很大一部分

假如我們要計算 1+2+....100億 的總和，很明顯，這就是一個 CPU 密集型程序

在【單核】CPU下，如果我們創建 4 個線程來分段計算，即：

1. 線程1計算 [1,25億）

2. ...... 以此類推

3. 線程4計算 [75億，100億]

我們來看下圖他們會發生什么？

由於是單核 CPU，所有線程都在等待 CPU 時間片。按照理想情況來看，四個線程執行的時間總和與一個線程5獨自完成是相等的，實際上我們還忽略了四個線程上下文切換的開銷

所以，單核CPU處理CPU密集型程序，這種情況並不太適合使用多線程

此時如果在 4 核CPU下，同樣創建四個線程來分段計算，看看會發生什么？

每個線程都有 CPU 來運行，並不會發生等待 CPU 時間片的情況，也沒有線程切換的開銷。理論情況來看效率提升了 4 倍

所以，如果是多核CPU 處理 CPU 密集型程序，我們完全可以最大化的利用 CPU 核心數，應用並發編程來提高效率

I/O密集型程序

與 CPU 密集型程序相對，一個完整請求，CPU運算操作完成之后還有很多 I/O 操作要做，也就是說 I/O 操作占比很大部分

我們都知道在進行 I/O 操作時，CPU是空閑狀態，所以我們要最大化的利用 CPU，不能讓其是空閑狀態

同樣在單核 CPU 的情況下：

從上圖中可以看出，每個線程都執行了相同長度的 CPU 耗時和 I/O 耗時，如果你將上面的圖多畫幾個周期，CPU操作耗時固定，將 I/O 操作耗時變為 CPU 耗時的 3 倍，你會發現，CPU又有空閑了，這時你就可以新建線程 4，來繼續最大化的利用 CPU。

綜上兩種情況我們可以做出這樣的總結：

線程等待時間所占比例越高，需要越多線程；線程CPU時間所占比例越高，需要越少線程。

到這里，相信你已經知道第一個【正確】使用多線程的場景了，那創建多少個線程是正確的呢？

創建多少個線程合適？

面試如果問到這個問題，這可是對你理論和實踐的統考。想完全答對，你必須要【精通/精通/精通】小學算術

從上面知道，我們有 CPU 密集型和 I/O 密集型兩個場景，不同的場景當然需要的線程數也就不一樣了

CPU 密集型程序創建多少個線程合適？

有些同學早已經發現，對於 CPU 密集型來說，理論上 線程數量 = CPU 核數（邏輯） 就可以了，但是實際上，數量一般會設置為 CPU 核數（邏輯）+ 1， 為什么呢？

《Java並發編程實戰》這么說：

計算密（CPU）集型的線程恰好在某時因為發生一個頁錯誤或者因其他原因而暫停，剛好有一個“額外”的線程，可以確保在這種情況下CPU周期不會中斷工作。

所以對於CPU密集型程序， CPU 核數（邏輯）+ 1 個線程數是比較好的經驗值的原因了

I/O密集型程序創建多少個線程合適？

上面已經讓大家按照圖多畫幾個周期（你可以動手將I/O耗時與CPU耗時比例調大，比如6倍或7倍），這樣你就會得到一個結論，對於 I/O 密集型程序：

最佳線程數 = (1/CPU利用率) = 1 + (I/O耗時/CPU耗時)

我這么體貼，當然擔心有些同學不理解這個公式，我們將上圖的比例手動帶入到上面的公式中：

這是一個CPU核心的最佳線程數，如果多個核心，那么 I/O 密集型程序的最佳線程數就是：

最佳線程數 = CPU核心數 * (1/CPU利用率) = CPU核心數 * 1 + (I/O耗時/CPU耗時)

說到這，有些同學可能有疑問了，要計算 I/O 密集型程序，是要知道 CPU 利用率的，如果我不知道這些，那要怎樣給出一個初始值呢？

按照上面公式，假如幾乎全是 I/O耗時，所以純理論你就可以說是 2N（N=CPU核數），當然也有說 2N + 1的，（我猜這個 1 也是 backup），沒有找到具體的推倒過程，在【並發編程實戰-8.2章節】截圖在此，大家有興趣的可以自己看看

理論上來說，理論上來說，理論上來說，這樣就能達到 CPU 100% 的利用率

如果理論都好用，那就用不着實踐了，也就更不會有調優的事出現了。不過在初始階段，我們確實可以按照這個理論之作為偽標准， 畢竟差也可能不會差太多，這樣調優也會更好一些

談完理論，咱們說點實際的，公式我看懂了（定性階段結束），但是我有兩個疑問：

1. 我怎么知道具體的 I/O耗時和CPU耗時呢？
2. 怎么查看CPU利用率？

沒錯，我們需要定量分析了

幸運的是，我們並不是第一個吃螃蟹的仔兒，其實有很多 APM （Application Performance Manager）工具可以幫我們得到准確的數據，學會使用這類工具，也就可以結合理論，在調優的過程得到更優的線程個數了。我這里簡單列舉幾個，具體使用哪一個，具體應用還需要你自己去調研選擇，受篇幅限制，暫不展開討論了

1. SkyWalking
2. CAT
3. zipkin

上面了解了基本的理論知識，那面試有可能問什么？又可能會以怎樣的方式提問呢？

面試小問

小問一

假設要求一個系統的 TPS（Transaction Per Second 或者 Task Per Second）至少為20，然后假設每個Transaction由一個線程完成，繼續假設平均每個線程處理一個Transaction的時間為4s

如何設計線程個數，使得可以在1s內處理完20個Transaction？

但是，但是，這是因為沒有考慮到CPU數目。家里又沒礦，一般服務器的CPU核數為16或者32，如果有80個線程，那么肯定會帶來太多不必要的線程上下文切換開銷（希望這句話你可以主動說出來），這就需要調優了，來做到最佳 balance

小問二

計算操作需要5ms，DB操作需要 100ms，對於一台 8個CPU的服務器，怎么設置線程數呢？

如果不知道請拿三年級期末考試題重新做（今天晚自習留下來），答案是：

線程數 = 8 * (1 + 100/5) = 168 (個)

那如果DB的 QPS（Query Per Second）上限是1000，此時這個線程數又該設置為多大呢？

同樣，這是沒有考慮 CPU 數目，接下來就又是細節調優的階段了

因為一次請求不僅僅包括 CPU 和 I/O操作，具體的調優過程還要考慮內存資源，網絡等具體內容

增加 CPU 核數一定能解決問題嗎？

看到這，有些同學可能會認為，即便我算出了理論線程數，但實際CPU核數不夠，會帶來線程上下文切換的開銷，所以下一步就需要增加 CPU 核數，那我們盲目的增加 CPU 核數就一定能解決問題嗎？

在講互斥鎖的內容是，我故意遺留了一個知識:

怎么理解這個公式呢？

這個結論告訴我們，假如我們的串行率是 5%，那么我們無論采用什么技術，最高也就只能提高 20 倍的性能。

如何簡單粗暴的理解串行百分比（其實都可以通過工具得出這個結果的）呢？來看個小 Tips：

Tips: 臨界區都是串行的，非臨界區都是並行的，用單線程執行臨界區的時間/用單線程執行(臨界區+非臨界區)的時間就是串行百分比

現在你應該理解我在講解 synchronized 關鍵字時所說的：

最小化臨界區范圍，因為臨界區的大小往往就是瓶頸問題的所在，不要像亂用try catch那樣一鍋端

總結

多線程不一定就比但線程高效，比如大名鼎鼎的 Redis （后面會分析），因為它是基於內存操作，這種情況下，單線程可以很高效的利用CPU。而多線程的使用場景一般時存在相當比例的I/O或網絡操作

另外，結合小學數學題，我們已經了解了如何從定性到定量的分析的過程，在開始沒有任何數據之前，我們可以使用上文提到的經驗值作為一個偽標准，其次就是結合實際來逐步的調優（綜合 CPU，內存，硬盤讀寫速度，網絡狀況等）了

最后，盲目的增加 CPU 核數也不一定能解決我們的問題，這就要求我們嚴格的編寫並發程序代碼了

靈魂追問

1. 我們已經知道創建多少個線程合適了，為什么還要搞一個線程池出來？
2. 創建一個線程都要做哪些事情？為什么說頻繁的創建線程開銷很大？
3. 多線程通常要注意共享變量問題，為什么局部變量就沒有線程安全問題呢？
4. ......

下一篇文章，我們就來說說，你熟悉又陌生的線程池問題

參考

感謝前輩們總結的精華，自己所寫的並發系列好多都參考了以下資料

• Java 並發編程實戰
• Java 並發編程之美
• 碼出高效
• Java 並發編程的藝術
• ......