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