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

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

當(dāng)我們的線程數(shù)量配置的過(guò)大，我們的線程與線程之間有會(huì)爭(zhēng)取 CPU 資源，這就會(huì)導(dǎo)致上下文切換。

多線程編程中一般線程的個(gè)數(shù)都大于 CPU 核心的個(gè)數(shù)，而一個(gè) CPU 核心在任意時(shí)刻只能被一個(gè)線程使用，為了讓這些線程都能得到有效執(zhí)行，CPU 采取的策略是為每個(gè)線程分配時(shí)間片并輪轉(zhuǎn)的形式。當(dāng)一個(gè)線程的時(shí)間片用完的時(shí)候就會(huì)重新處于就緒狀態(tài)讓給其他線程使用，這個(gè)過(guò)程就屬于一次上下文切換。

概括來(lái)說(shuō)就是：當(dāng)前任務(wù)在執(zhí)行完 CPU 時(shí)間片切換到另一個(gè)任務(wù)之前會(huì)先保存自己的狀態(tài)，以便下次再切換回這個(gè)任務(wù)時(shí)，可以再加載這個(gè)任務(wù)的狀態(tài)。任務(wù)從保存到再加載的過(guò)程就是一次上下文切換。

上下文切換通常是計(jì)算密集型的。也就是說(shuō)，它需要相當(dāng)可觀的處理器時(shí)間，在每秒幾十上百次的切換中，每次切換都需要納秒量級(jí)的時(shí)間。所以，上下文切換對(duì)系統(tǒng)來(lái)說(shuō)意味著消耗大量的 CPU 時(shí)間，事實(shí)上，可能是操作系統(tǒng)中時(shí)間消耗最大的操作。

Linux 相比與其他操作系統(tǒng)(包括其他類 Unix 系統(tǒng))有很多的優(yōu)點(diǎn)，其中有一項(xiàng)就是，其上下文切換和模式切換的時(shí)間消耗非常少。

上下文切換過(guò)多，必然增加線程的執(zhí)行時(shí)間，影響了整體執(zhí)行效率。

如果我們?cè)O(shè)置的線程池?cái)?shù)量太小的話，如果同一時(shí)間有大量任務(wù)/請(qǐng)求需要處理，可能會(huì)導(dǎo)致大量的請(qǐng)求/任務(wù)在任務(wù)隊(duì)列中排隊(duì)等待執(zhí)行，甚至?xí)霈F(xiàn)任務(wù)隊(duì)列滿了之后任務(wù)/請(qǐng)求無(wú)法處理的情況，或者大量任務(wù)堆積在任務(wù)隊(duì)列導(dǎo)致 OOM。這樣很明顯是有問(wèn)題的！ CPU 根本沒(méi)有得到充分利用。

線程數(shù)該配置多少呢？網(wǎng)上有一個(gè)比較通用的公式可以作為參考：

有一個(gè)簡(jiǎn)單并且適用面比較廣的公式：CPU 密集型任務(wù)(N+1)： 這種任務(wù)消耗的主要是 CPU 資源，可以將線程數(shù)設(shè)置為 N(CPU 核心數(shù))+1，比 CPU 核心數(shù)多出來(lái)的一個(gè)線程是為了防止線程偶發(fā)的缺頁(yè)中斷，或者其它原因?qū)е碌娜蝿?wù)暫停而帶來(lái)的影響。一旦任務(wù)暫停，CPU 就會(huì)處于空閑狀態(tài)，而在這種情況下多出來(lái)的一個(gè)線程就可以充分利用 CPU 的空閑時(shí)間。

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

總結(jié)

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

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。