與Peter Lawrey合作撰寫 。

幾天前，我對使用新的Java8聲明式的排序性能提出了嚴重的問題。 在這里查看博客文章。 在那篇文章中，我僅指出了問題所在，但在這篇文章中，我將更深入地了解和解釋問題的原因。 這將通過使用聲明式樣式重現問題，然后一點一點地修改代碼來完成，直到我們消除了性能問題并保留了使用舊樣式比較所期望的性能。

回顧一下，我們對此類的實例進行排序：

private static class MyComparableInt{private int a,b,c,d;public MyComparableInt(int i) {a = i%2;b = i%10;c = i%1000;d = i;}public int getA() return a;public int getB() return b;public int getC() return c;public int getD() return d; }

使用聲明性的Java 8樣式（如下），大約需要6秒鐘才能排序10m個實例：

List mySortedList = myComparableList.stream().sorted(Comparator.comparing(MyComparableInt::getA).thenComparing(MyComparableInt::getB).thenComparing(MyComparableInt::getC).thenComparing(MyComparableInt::getD)).collect(Collectors.toList());

使用自定義排序器（如下）花費了約1.6秒的時間來排序10m個實例。

這是排序的代碼調用：

List mySortedList = myComparableList.stream().sorted(MyComparableIntSorter.INSTANCE).collect(Collectors.toList());

使用此自定義比較器：

public enum MyComparableIntSorter implements Comparator<MyComparableInt>{INSTANCE;@Overridepublic int compare(MyComparableInt o1, MyComparableInt o2) {int comp = Integer.compare(o1.getA(), o2.getA());if(comp==0){comp = Integer.compare(o1.getB(), o2.getB());if(comp==0){comp = Integer.compare(o1.getC(), o2.getC());if(comp==0){comp = Integer.compare(o1.getD(), o2.getD());}}}return comp;}}

讓我們在類中創建一個comparing方法，以便我們可以更緊密地分析代碼。 comparing方法的原因是允許我們輕松交換實現，但將調用代碼保持不變。

在所有情況下，這都是comparing方法的調用方式：

List mySortedList = myComparableList.stream().sorted(comparing(MyComparableInt::getA,MyComparableInt::getB,MyComparableInt::getC,MyComparableInt::getD)).collect(Collectors.toList());

比較的第一個實現幾乎是jdk中的一個副本。

public static <T, U extends Comparable<? super U>> Comparator<T> comparing(Function<? super T, ? extends U> ke1,Function<? super T, ? extends U> ke2,Function<? super T, ? extends U> ke3,Function<? super T, ? extends U> ke4){return Comparator.comparing(ke1).thenComparing(ke2).thenComparing(ke3).thenComparing(ke4);}

毫不奇怪，這花了大約6秒鐘才能完成測試-但是至少我們重現了該問題，并為進一步進行奠定了基礎。

讓我們看一下該測試的飛行記錄：

可以看出有兩個大問題：

lambda$comparing方法中的性能問題

反復調用Integer.valueOf （自動裝箱）

讓我們嘗試處理比較方法中的第一個方法。 乍一看，這似乎很奇怪，因為當您查看代碼時，該方法沒有發生太多事情。 然而，隨著代碼找到該函數的正確實現，虛擬表查找將在這里廣泛進行。 當從一行代碼中調用多種方法時，將使用虛擬表查找。 我們可以通過下面的comparing實現消除這種延遲源。 通過擴展Function接口的所有用途，每一行只能調用一個實現，因此可以內聯該方法。

public static <T, U extends Comparable<? super U>> Comparator<T> comparing(Function<? super T, ? extends U> ke1,Function<? super T, ? extends U> ke2,Function<? super T, ? extends U> ke3,Function<? super T, ? extends U> ke4){return (c1, c2) -> {int comp = compare(ke1.apply(c1), ke1.apply(c2));if (comp == 0) {comp = compare(ke2.apply(c1), ke2.apply(c2));if (comp == 0) {comp = compare(ke3.apply(c1), ke3.apply(c2));if (comp == 0) {comp = compare(ke4.apply(c1), ke4.apply(c2));}}}return comp;};}

通過展開方法，JIT應該能夠內聯方法查找。

確實，時間幾乎減少了一半至3.5秒，讓我們來看一下此運行的飛行記錄：

當我第一次看到此消息時，我感到非常驚訝，因為到目前為止，我們還沒有進行任何更改來減少對Integer.valueOf的調用，但是該百分比已經下降了！ 發生了什么實際上發生在這里的是，由于變化，我們提出允許內聯，該Integer.valueOf已內聯，并采取了時間Integer.valueOf被呼叫者指責（ lambda$comparing ），它內聯了被調用者（ Integer.valueOf ）。 這是事件探查器中的一個常見問題，因為他們可能會誤解應歸咎于哪種方法，尤其是在內聯發生時。

但是我們知道在之前的Flight Recording Integer.valueOf
突出顯示了，因此讓我們通過comparing實現comparing刪除，看看是否可以進一步減少時間。

return (c1, c2) -> {int comp = compare(ke1.applyAsInt(c1), ke1.applyAsInt(c2));if (comp == 0) {comp = compare(ke2.applyAsInt(c1), ke2.applyAsInt(c2));if (comp == 0) {comp = compare(ke3.applyAsInt(c1), ke3.applyAsInt(c2));if (comp == 0) {comp = compare(ke4.applyAsInt(c1), ke4.applyAsInt(c2));}}}return comp; };

使用此實現，時間可以縮短到1.6s，這是我們使用自定義比較器可以實現的。

讓我們再次查看此運行的飛行記錄：

現在，所有時間都在使用實際的排序方法，而不是開銷。

總之，我們從這次調查中學到了一些有趣的事情：

由于自動裝箱和虛擬表查找的成本，在某些情況下，使用新的Java8聲明式排序將比編寫自定義比較器慢4倍。

FlightRecorder雖然比其他分析器要好（有關此問題，請參閱我的第一篇博客文章 ），但仍將時間歸因于錯誤的方法，尤其是在進行內聯時。

翻譯自: https://www.javacodegeeks.com/2015/01/java8-lambdas-sorting-performance-pitfall-explained.html

總結

以上是生活随笔為你收集整理的Java8 Lambdas：解释性能缺陷的排序的全部內容，希望文章能夠幫你解決所遇到的問題。

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