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