線程池的大小應該遠大於內核的數量+ 1

自定義線程池的建議大小是number_of_cores + 1（請參閱here和here）。因此，可以說有一個系統上的應用程序春季用2芯和配置是這樣的線程池的大小應該遠大於內核的數量+ 1

<task:executor id="taskExecutor" 
pool-size="#{T(java.lang.Runtime).getRuntime().availableProcessors() + 1}" /> 
<task:annotation-driven executor="taskExecutor" />

在這種情況下會有多個請求之間共享一個ExecutorService的。所以如果有10個請求到達服務器，其中只有3個可以在ExecutorService中同時執行。這可能會造成瓶頸，並且結果會隨着請求數量的增加而變差（請記住，默認情況下，tomcat可以處理多達200個併發請求= 200個線程）。該應用程序可以在沒有任何池的情況下執行得更好

通常一個核心可以同時處理多個線程。例如我創建了一個服務，該服務調用兩次https://httpbin.org/delay/2。每次通話需要2秒鐘執行。所以如果沒有使用線程池，服務平均響應4.5秒（用20個同時請求測試）。如果使用線程池，則響應會因池大小和硬件而異。我使用不同池大小的4核心機器運行測試。下面是用最小，最大和平均響應時間測試結果以毫秒爲單位

從結果來看，可以得出結論，最好的平均時間與最大池大小。池中有5個（4個核心+ 1）線程的平均時間比沒有池的結果更差。所以在我看來，如果一個請求沒有花費太多CPU時間，那麼將線程池限制爲web應用程序中的核心數+ 1是沒有意義的。

有沒有人發現任何錯誤的設置池大小爲20（或更多）在2或4核心機器上的Web服務是不是CPU要求？

來源

2015-12-14 lolotron

您鏈接到的兩個頁面明確表示這僅適用於未封鎖的CPU綁定任務。

您有在遠程計算機上等待的任務，因此此建議不適用。

忽略不適用於您的建議沒有任何問題，因此您可以並且應該增加線程池大小。

好建議自帶的理由，所以你可以當它變成不好的建議告訴我們。如果你不明白爲什麼要做某件事，那麼你已經陷入了貨物崇拜節目的陷阱，即使它不再需要甚至變得有害時，你也會繼續這樣做。我清楚地提供的鏈接的

Raymond Chen，在他的博客「舊的新」

來源

2015-12-14 23:09:15

在我看來既不是國家「暢通，CPU密集型任務」。在網絡應用程序（這是當今大多數應用程序）中，很少有代碼只是CPU綁定（DB調用，WS調用...），所以Amdahl法則可以在少數情況下應用。無論如何，謝謝你的清楚解釋 – lolotron

線程池的大小應該遠大於內核的數量+ 1

回答

相關問題