此方法的規(guī)范：https://docs.oracle.com/javase/7/docs/api/java/util/concurrent/Executors.html#newCachedThreadPool()創(chuàng)建一個(gè)線程池，該線程池根據(jù)需要?jiǎng)?chuàng)建新線程，但會(huì)在可用時(shí)重用以前構(gòu)造的線程。這些池通常會(huì)提高執(zhí)行許多短期異步任務(wù)的程序的性能。如果可用，對(duì)執(zhí)行的調(diào)用將重用以前構(gòu)造的線程。如果沒有可用的現(xiàn)有線程，將創(chuàng)建一個(gè)新線程并將其添加到池中。60 秒內(nèi)未使用的線程將被終止并從緩存中刪除。因此，保持空閑時(shí)間足夠長的池不會(huì)消耗任何資源。請(qǐng)注意，可以使用 ThreadPoolExecutor 構(gòu)造函數(shù)創(chuàng)建具有相似屬性但不同細(xì)節(jié)（例如，超時(shí)參數(shù)）的池。從這個(gè)描述中我不清楚 - 在一個(gè)程序中擁有多個(gè)這樣的池是否安全？或者我是否會(huì)遇到這樣一種情況，即一個(gè)池在多個(gè)線程上停頓并凍結(jié)其他池？
1 回答
瀟湘沐
TA貢獻(xiàn)1816條經(jīng)驗(yàn) 獲得超6個(gè)贊
我認(rèn)為對(duì)此沒有明確的是/否答案。
一方面，ThreadPoolExecutor 實(shí)例消耗的線程數(shù)量不是有限的。JVM 體系結(jié)構(gòu)本身不限制線程數(shù)。
另一方面，操作系統(tǒng)/環(huán)境可能會(huì)有一些限制：
操作系統(tǒng)可能對(duì)其支持的本機(jī)線程總數(shù)有硬性限制。
操作系統(tǒng)可能會(huì)限制給定進(jìn)程（在本例中為 JVM）可以創(chuàng)建的本機(jī)線程數(shù)。這可以使用
ulimit或cgroup限制以及其他可能的方式來完成。在典型的 64 位 JVM 上，Java 線程堆棧的大小為 1MB（默認(rèn)情況下）。如果您嘗試使用
start()太多線程，則可能會(huì)耗盡內(nèi)存并出現(xiàn) OOME。如果有足夠多的線程和/或過多的線程上下文切換，線程調(diào)度程序（在操作系統(tǒng)中）可能會(huì)遇到困難。
（上下文切換通常發(fā)生在線程執(zhí)行阻塞系統(tǒng)調(diào)用或必須等待鎖定或通知時(shí)。每次切換上下文時(shí)都會(huì)產(chǎn)生與硬件相關(guān)的開銷：保存和恢復(fù)寄存器、切換虛擬內(nèi)存上下文、刷新內(nèi)存緩存等。 )
第三，除了線程池的數(shù)量和大小之外，還有其他因素可能會(huì)導(dǎo)致問題。例如，如果線程任務(wù)相互交互，您可能會(huì)遇到以下問題：
鎖定共享對(duì)象時(shí)發(fā)生死鎖，
過多的共享鎖爭用導(dǎo)致資源匱乏，
太多的工作導(dǎo)致超時(shí)，或者
優(yōu)先級(jí)倒置問題……如果您嘗試使用優(yōu)先級(jí)來“管理”工作量。
所以 ...
在一個(gè)程序中擁有多個(gè)這樣的池是否安全？
或者我是否會(huì)遇到這樣一種情況，即一個(gè)池在多個(gè)線程上停滯并凍結(jié)其他池。
除非任務(wù)以某種方式相互作用，否則您不太可能會(huì)遇到“停頓” 。
但是，如果您有太多可運(yùn)行的線程競爭 CPU，每個(gè)線程將（平均）獲得有限數(shù)量的可用內(nèi)核中的一小部分。鎖爭用或過多的上下文切換會(huì)進(jìn)一步減慢速度。
添加回答
舉報(bào)
0/150
提交
取消