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

2.并發(fā)編程適用于什么場景？

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

1.并發(fā)編程在所有場景下都是快的嗎？

2.知道它很快，何為快？怎樣度量？

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

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

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

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

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

1.CPU 密集型程序

2.I/O 密集型程序

CPU 密集型程序

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

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

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

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

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

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

我們來看下圖他們會發(fā)生什么？

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

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

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

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

所以，如果是多核CPU 處理 CPU 密集型程序，我們完全可以最大化的利用 CPU 核心數(shù)，應(yīng)用并發(fā)編程來提高效率。

I/O密集型程序

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

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

同樣在單核 CPU 的情況下：

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

綜上兩種情況我們可以做出這樣的總結(jié)：線程等待時間所占比例越高，需要越多線程；線程CPU時間所占比例越高，需要越少線程。

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

3.創(chuàng)建多少個線程合適？

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

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

CPU 密集型程序創(chuàng)建多少個線程合適？

有些同學早已經(jīng)發(fā)現(xiàn)，對于 CPU 密集型來說，理論上?線程數(shù)量 = CPU 核數(shù)（邏輯）?就可以了，但是實際上，數(shù)量一般會設(shè)置為?CPU 核數(shù)（邏輯）+ 1， 為什么呢？

《Java并發(fā)編程實戰(zhàn)》這么說：計算(CPU)密集型的線程恰好在某時因為發(fā)生一個頁錯誤或者因其他原因而暫停，剛好有一個“額外”的線程，可以確保在這種情況下CPU周期不會中斷工作。

所以對于CPU密集型程序， ?CPU 核數(shù)（邏輯）+ 1?個線程數(shù)是比較好的經(jīng)驗值的原因了。

I/O密集型程序創(chuàng)建多少個線程合適？

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

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

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

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

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

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

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

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

如果理論都好用，那就用不著實踐了，也就更不會有調(diào)優(yōu)的事出現(xiàn)了。不過在初始階段，我們確實可以按照這個理論之作為偽標準， 畢竟差也可能不會差太多，這樣調(diào)優(yōu)也會更好一些

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

1.我怎么知道具體的 I/O耗時和CPU耗時呢？

2.怎么查看CPU利用率？

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

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

1.SkyWalking

2.CAT

3.zipkin

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

面試小問1

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

如何設(shè)計線程個數(shù)，使得可以在1s內(nèi)處理完20個Transaction？

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

面試小問2

計算操作需要5ms，DB操作需要 100ms，對于一臺 8個CPU的服務(wù)器，怎么設(shè)置線程數(shù)呢？

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

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

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

同樣，這是沒有考慮 CPU 數(shù)目，接下來就又是細節(jié)調(diào)優(yōu)的階段了。

因為一次請求不僅僅包括 CPU 和 I/O操作，具體的調(diào)優(yōu)過程還要考慮內(nèi)存資源，網(wǎng)絡(luò)等具體內(nèi)容。

增加 CPU 核數(shù)一定能解決問題嗎？

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

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

怎么理解這個公式呢？

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

如何簡單粗暴的理解串行百分比（其實都可以通過工具得出這個結(jié)果的）呢？來看個小 Tips：臨界區(qū)都是串行的，非臨界區(qū)都是并行的，用單線程執(zhí)行臨界區(qū)的時間/用單線程執(zhí)行(臨界區(qū)+非臨界區(qū))的時間就是串行百分比。

現(xiàn)在你應(yīng)該理解我在講解 synchronized 關(guān)鍵字時所說的：最小化臨界區(qū)范圍，因為臨界區(qū)的大小往往就是瓶頸問題的所在，不要像亂用try catch那樣一鍋端。

4.總結(jié)

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

另外，結(jié)合小學數(shù)學題，我們已經(jīng)了解了如何從定性到定量的分析的過程，在開始沒有任何數(shù)據(jù)之前，我們可以使用上文提到的經(jīng)驗值作為一個偽標準，其次就是結(jié)合實際來逐步的調(diào)優(yōu)（綜合 CPU，內(nèi)存，硬盤讀寫速度，網(wǎng)絡(luò)狀況等）了。

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