簡單說一下吧！拿我們生活中非常常見的一例子來說：并不是人多就能把事情做好，增加了溝通交流成本。你本來一件事情只需要3個人做，你硬是拉來了6個人，會提升做事效率嘛？我想并不會。

線程數量過多的影響也是和我們分配多少人做事情一樣，對于線程來說主要是增加了上下文切換成本。不清楚什么是上下文切換的話，可以看我下面的介紹。

當我們的線程數量配置的過大，我們的線程與線程之間有會爭取 CPU 資源，這就會導致上下文切換。

多線程編程中一般線程的個數都大于 CPU 核心的個數，而一個 CPU 核心在任意時刻只能被一個線程使用，為了讓這些線程都能得到有效執行，CPU 采取的策略是為每個線程分配時間片并輪轉的形式。當一個線程的時間片用完的時候就會重新處于就緒狀態讓給其他線程使用，這個過程就屬于一次上下文切換。

概括來說就是：當前任務在執行完 CPU 時間片切換到另一個任務之前會先保存自己的狀態，以便下次再切換回這個任務時，可以再加載這個任務的狀態。任務從保存到再加載的過程就是一次上下文切換。

上下文切換通常是計算密集型的。也就是說，它需要相當可觀的處理器時間，在每秒幾十上百次的切換中，每次切換都需要納秒量級的時間。所以，上下文切換對系統來說意味著消耗大量的 CPU 時間，事實上，可能是操作系統中時間消耗最大的操作。

Linux 相比與其他操作系統(包括其他類 Unix 系統)有很多的優點，其中有一項就是，其上下文切換和模式切換的時間消耗非常少。

上下文切換過多，必然增加線程的執行時間，影響了整體執行效率。

如果我們設置的線程池數量太小的話，如果同一時間有大量任務/請求需要處理，可能會導致大量的請求/任務在任務隊列中排隊等待執行，甚至會出現任務隊列滿了之后任務/請求無法處理的情況，或者大量任務堆積在任務隊列導致 OOM。這樣很明顯是有問題的！ CPU 根本沒有得到充分利用。

線程數該配置多少呢？網上有一個比較通用的公式可以作為參考：

有一個簡單并且適用面比較廣的公式：CPU 密集型任務(N+1)： 這種任務消耗的主要是 CPU 資源，可以將線程數設置為 N(CPU 核心數)+1，比 CPU 核心數多出來的一個線程是為了防止線程偶發的缺頁中斷，或者其它原因導致的任務暫停而帶來的影響。一旦任務暫停，CPU 就會處于空閑狀態，而在這種情況下多出來的一個線程就可以充分利用 CPU 的空閑時間。

I/O 密集型任務(2N)： 這種任務應用起來，系統會用大部分的時間來處理 I/O 交互，而線程在處理 I/O 的時間段內不會占用 CPU 來處理，這時就可以將 CPU 交出給其它線程使用。因此在 I/O 密集型任務的應用中，我們可以多配置一些線程，具體的計算方法是 2N。

總結

以上是生活随笔為你收集整理的java 多线程池_Java项目中，线程池中线程数量太大会有什么影响？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。