假設我們有一個列表并且想要選擇滿足某個屬性的所有元素（比如一些函數 f）。有 3 種方法可以并行執行此過程。一 ：listA.parallelStream.filter(element -> f(element)).collect(Collectors.toList());二：listA.parallelStream.collect(Collectors.partitioningBy(element -> f(element))).get(true);三：ExecutorService executorService = Executors.newFixedThreadPool(nThreads);//separate the listA into several batchesfor each batch { Future<List<T>> result = executorService.submit(() -> { // test the elements in this batch and return the validate element list });}//merge the results from different threads.假設測試功能是 CPU 密集型任務。我想知道哪種方法更有效。非常感謝。
2 回答
收到一只叮咚
TA貢獻1821條經驗 獲得超5個贊
一和二使用 ForkJoinPool，它專為并行處理一項任務而設計，而 ThreadPoolExecutor 用于并發處理獨立任務。所以一和二應該更快。
瀟瀟雨雨
TA貢獻1833條經驗 獲得超4個贊
當您使用 時.filter(element -> f(element)).collect(Collectors.toList())，它會將匹配的元素收集到 a 中List，而.collect(Collectors.partitioningBy(element -> f(element)))將所有元素收集到兩個列表中的任何一個中，然后您刪除其中一個并僅通過 檢索匹配項列表.get(true)。
很明顯，第二個變體只能在最佳情況下與第一個變體相當，即如果所有元素無論如何都與謂詞匹配，或者當 JVM 的優化器能夠刪除冗余工作時。在最壞的情況下，例如當沒有元素匹配時，第二個變體收集所有元素的列表，然后才刪除它，而第一個變體不會收集任何元素。
第三個變體沒有可比性，因為您沒有展示實際的實現，而只是一個草圖。將假設的實現與實際進行比較是沒有意義的。您描述的邏輯與并行流實現的邏輯相同。所以你只是在重新發明輪子。您可能會做一些比參考實現稍微好一點的事情，或者只是更好地針對您的特定任務量身定制，但是您忽略 Stream API 實現者在持續數年的開發過程中已經考慮過的事情的可能性要高得多。
所以我不會對你的第三個變體下任何賭注。如果我們增加您完成第三個變體的實現所需的時間，那么它永遠不會比僅使用其他變體中的任何一個更有效。
所以第一個變體是最有效的變體，特別是因為它也是最簡單、最易讀、直接表達你的意圖的。
添加回答
舉報
0/150
提交
取消