Java中有多少 Futures 太多了？

Question

在嘗試確定 Java 數據處理服務器中的任務應該如何分解時，我需要知道有多少 Futures 對 ExecutorService 來說太多了。

據我了解，ExecutorServices 帶有一個重量級線程池，像處理綠色線程一樣處理 Futures，這意味着在 Futures 之間執行上下文切換的成本非常小。 這是真的？

我應該向 ExecutorService 提交數百萬個 Futures（使用池中固定數量的線程）嗎？

我是否可以期望將許多非常短暫的期貨（10 毫秒）提交到 Executor 服務中而不會看到嚴重的性能下降？

Answer 1

您將Future混為一談，它表示異步操作的可能結果與Thread ，后者表示對Callable執行處理的能力（至少在Executor的情況下）。

沒有什么可以阻止您在線程池上調用submit數百萬次並獲取大量Future對象列表供您等待。 如果應用程序將繼續運行並且您不需要處理結果，您甚至不需要等待它們完成。

但。

如果您創建所有這些作業，它們將需要內存來保持其狀態。 如果該內存以某種方式是作業輸入或作業執行結果的一部分，那么您將為所有這些任務提供堆空間。 你不能永遠這樣做。 從本質上講，如果您要將大量工作拉入進程以在后台運行，則需要考慮某種限制。

Answer 2

據我了解，ExecutorServices 帶有一個重量級線程池，處理 Futures 就像它們是綠色線程一樣

那不正確。 如果我們忽略花里胡哨，ExecutorService 由一組工作線程和一個阻塞任務隊列組成。 隊列中的每個任務都是一個包裝器，其中包含您的一個任務和一個Future 。

每個工作線程永遠循環，

• 從隊列中挑選一個任務，
• 調用Runnable或Callable對象的run()或call(...)方法，
• 使用您的方法返回的值或您的方法拋出的異常完成Future 。
• 回去等待另一個任務。

唯一的線程是“重量級”工作線程。 一旦其中一個工作線程開始處理任務，在任務完成之前它不會做任何其他事情。 尚未啟動的任務只是隊列中的對象，一旦 Future 完成，Executor 就會忘記每個任務和 Future 對象。 在您自己的代碼丟棄對它們的引用后，這些將不會繼續存在。

Answer 3

我應該向 ExecutorService 提交數百萬個期貨嗎？

你可以，但你應該評估可能的時間開銷。 處理單獨的 Future 對象的開銷很小，但大於零。 所以任務數量越少越好。 另一方面，當任務數量小於處理器數量（即，與超線程相關的處理器內核數量）時，並行度降低，整體執行時間增加。

讓你有 100 萬個 10 毫秒的任務，你的電腦有 8 個內核。 然后 1250 秒的總執行時間增加了 (10*8/2) = 40 毫秒，因為最后並行度降低，並且任務切換增加了 125 毫秒（我對每個任務切換的評估只有 1 個 useq） . 如果您有 100000 個 100 毫秒的任務，那么執行時間預計仍為 1250 秒，加上尾部 400 毫秒和開關 12.5 毫秒。 無論哪種方式，時間開銷都可以忽略不計，但如果您的任務明顯短於或長於 10...100 間隔，則時間開銷可能會增加。