我是一個出色的多任務處理者。 即使我在寫這篇文章，我仍然可以為昨天在一個大家都對我陌生的聚會上發表的言論感到尷尬。 好消息是，我并不孤單– Java 8在多任務處理方面也相當出色。 讓我們看看如何。

Java 8中引入的關鍵新功能之一是并行數組操作。 這包括使用自動利用多核體系結構的Lambda表達式對項目進行排序，過濾和分組的功能。 作為Java開發人員，這里的承諾是在我們付出最小努力的情況下立即獲得性能提升。 很酷

因此，問題就變成了：這東西有多快？何時使用？ 好吧，快速的答案令人遺憾- 這取決于 。 想知道什么？ 繼續閱讀。

新的API

新的Java 8并行操作API非常漂亮。 讓我們看一下我們將要測試的一些。

要使用多個核對數組進行排序 ，您要做的就是– Arrays.parallelSort(numbers);

A 組收集到不同的組基于特定標準（如黃金和非素數） - Map<Boolean, List<Integer>> groupByPrimary = numbers.parallelStream().collect(Collectors.groupingBy(s -> Utility.isPrime(s)));

要過濾掉值，您要做的就是– Integer[] prims = numbers.parallelStream().filter(s -> Utility.isPrime(s)).toArray();

將此與自己編寫多線程實現進行比較。 大大提高了生產力！ 我個人對這種新體系結構喜歡的東西是Spliterators的新概念，用于將目標集合拆分為多個塊，然后可以并行處理這些塊并縫合回去。 就像他們的老兄迭代器用于遍歷項目集合一樣，這是一種靈活的體系結構，使您可以編寫自定義行為來遍歷和拆分可以直接插入的集合。

那么它的表現如何呢？

為了驗證這一點，我檢查了并行操作在兩種情況下（ 低和高競爭情況）如何工作。 原因是本身運行多核算法通常會產生不錯的結果。 當踢腳程序開始在實際服務器環境中運行時，它就會進入。 那就是大量池線程不斷爭奪寶貴的CPU周期來處理消息或用戶請求的地方。 這就是事情開始放緩的地方。 為此，我設置了以下測試 。 我將100K個整數的數組隨機化，其值范圍在零到一百萬之間。 然后，我使用傳統的順序方法和新的Java 8并行API對它們進行排序，分組和過濾操作。 結果并不令人驚訝。

• Quicksort現在快了4.7倍。
• 分組現在快5倍倍。
• 現在， 過濾速度提高了5.5倍。

一個快樂的結局？ 不幸的是沒有 。

*結果與運行100次的其他測試一致。*測試機器為MBP i7四核。

那么在負載下會發生什么呢？

到目前為止，情況一直很糟糕，原因是在CPU周期的線程之間幾乎沒有爭用。 這是一種理想的情況，但是不幸的是，在現實生活中這種情況很少發生。 為了模擬一個與您在現實環境中通常看到的場景更相像的場景，我設置了第二個測試。 該測試運行相同的算法集，但是這次在十個并發線程上執行它們，以模擬在服務器承受壓力（ 將其命名為Kermit！ ）時處理服務器執行的十個并發請求。 然后，將使用傳統方法或新的Java 8 API依次處理每個請求。

結果

• 現在排序速度僅加快了20％， 下降了 23倍。
• 現在， 過濾速度僅提高了20％， 下降了25倍 。
• 現在， 分組 速度降低了15％ 。

較高的規模和競爭水平很可能會使這些數字進一步下降。 原因是在已經是多線程環境的環境中添加線程對您沒有幫助。 我們只有多少個CPU，而不是線程。

結論

盡管這些都是非常強大且易于使用的API，但它們并不是靈丹妙藥。 我們仍然需要對何時使用它們做出判斷。 如果事先知道您將并行執行多個處理操作，那么考慮使用排隊體系結構將并行操作的數量與您可用的實際處理器數量相匹配可能是個好主意。 這里最困難的部分是運行時性能將取決于實際的硬件體系結構和壓力級別。 您的代碼很可能只會在負載測試或生產過程中看到這些代碼，這使這種經典情況“易于編碼，難以調試”。

翻譯自: https://www.javacodegeeks.com/2014/04/new-parallelism-apis-in-java-8-behind-the-glitz-and-glamour.html

總結

以上是生活随笔為你收集整理的Java 8中新的并行API：Glitz和Glamour的背后的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。