1樓：香香香香香香
我的理解是你可以想象一種極限的情況，乙個任務的幾乎全部時間都消耗在了cpu計算上， 假設任務是無休止的，算不完的，那麼假設有8個cpu，就只能有8個執行緒在跑，多了也只能等待，這8個執行緒是永遠也跑不完的。當然，現實情況是：任務是能跑完的，乙個任務跑完，跑下個任務之前是有間隙的，這時候如果有個執行緒一直在等cpu，他這個時候是不是馬上就進cpu裡跑了。
就像春節買個無座回家，別人下站，座位的下個主人上車之前，你是可以坐一會的，這樣座位就充分利用起來了。
2樓：大閒人柴毛毛
執行緒池究竟設成多大是要看你給執行緒池處理什麼樣的任務，任務型別不同，執行緒池大小的設定方式也是不同的。
任務一般可分為：CPU密集型、IO密集型、混合型，對於不同型別的任務需要分配不同大小的執行緒池。
CPU密集型任務
盡量使用較小的執行緒池，一般為CPU核心數+1。
因為CPU密集型任務使得CPU使用率很高，若開過多的執行緒數，只能增加上下文切換的次數，因此會帶來額外的開銷。
IO密集型任務
可以使用稍大的執行緒池，一般為2*CPU核心數。
IO密集型任務CPU使用率並不高，因此可以讓CPU在等待IO的時候去處理別的任務，充分利用CPU時間。
混合型任務
可以將任務分成IO密集型和CPU密集型任務，然後分別用不同的執行緒池去處理。
只要分完之後兩個任務的執行時間相差不大，那麼就會比序列執行來的高效。
因為如果劃分之後兩個任務執行時間相差甚遠，那麼先執行完的任務就要等後執行完的任務，最終的時間仍然取決於後執行完的任務，而且還要加上任務拆分與合併的開銷，得不償失。
3樓：zhangya
我是搬運工，以下答案均來自於併發程式設計網（如何合理地估算執行緒池大小？）。我只是部分整理了一下。
一般說來，大家認為執行緒池的大小經驗值應該這樣設定：（其中N為CPU的個數）
如果是CPU密集型應用，則執行緒池大小設定為N+1
如果是IO密集型應用，則執行緒池大小設定為2N+1
如果一台伺服器上只部署這乙個應用並且只有這乙個執行緒池，那麼這種估算或許合理，具體還需自行測試驗證。
但是，IO優化中，這樣的估算公式可能更適合：
最佳執行緒數目 = （（執行緒等待時間+執行緒CPU時間）/執行緒CPU時間 ）* CPU數目
因為很顯然，執行緒等待時間所佔比例越高，需要越多執行緒。執行緒CPU時間所佔比例越高，需要越少執行緒。
下面舉個例子：
比如平均每個執行緒CPU執行時間為0.5s，而執行緒等待時間（非CPU執行時間，比如IO）為1.5s，CPU核心數為8，那麼根據上面這個公式估算得到：
((0.5+1.5)/0.
5)*8=32。這個公式進一步轉化為：
最佳執行緒數目 = （執行緒等待時間與執行緒CPU時間之比 + 1）* CPU數目
剛剛說到的執行緒池大小的經驗值，其實是這種公式的一種估算值。
4樓：吳焱
對於計算密集型的程式，執行緒數應當等於核心數，但是再怎麼計算密集，總有一些IO吧，所以再加乙個執行緒來把等待IO的CPU時間利用起來
5樓：william
個人理解，與CPU核數相等，表示滿核執行,+1的話表示在CPU上存在競爭，兩者的競爭力不一樣。稍微高一點負荷是不影響的。
NGINX引入了執行緒池
叔度 先簡單答一下。Nginx引入執行緒池是為了解決因為某些長時間阻塞的呼叫導致效能下降的問題。比如文章裡提到的cache伺服器服務大檔案就是乙個例子。還有一些大量計算的應用也可以嘗試用它來解決。至於實際效果？呵呵，你測測看啊。跑一下題，作為乙個對Nginx研究非常深入的團隊 我們是開發Tengin...
Golang 需要執行緒池嗎
至忖惻 go的執行緒開銷挺小，就是建立幾萬個執行緒也就占用幾百兆的記憶體而已。如果你的併發任務數不會達到萬級，就沒有太大必要用執行緒池來控制資源 如果是極其頻繁地建立 銷毀協程，又想得到高效能，那是需要的。但，如果以這種方式要效能，可能得考慮下實現方式是否合理。我想多數程式不需要，目前的gorout...
執行緒池併發引起的問題？
KindKing 這樣啊，首先咱要弄明白執行緒池是執行緒池，資料庫連線池是資料庫連線池，他們是不一樣的啊，感覺你有點混淆啊 我在這裡在你沒有描述錯誤的前提下覺得是這樣的 你執行緒池1000，是指你同時1000個請求併發訪問，這裡沒問題，你的併發請求全部通過，我認為也是沒問題的，第一，你設定1000併...