Java8 Lambdas：解释性能缺陷的排序

与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秒钟才能完成测试-但是至少我们重现了该问题，并为进一步进行奠定了基础。

让我们看一下该测试的飞行记录：

屏幕截图2015年1月22日的11.56.20

可以看出有两个大问题：

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秒，让我们来看一下此运行的飞行记录：

屏幕截图2015年1月22日的11.57.58

当我第一次看到此消息时，我感到非常惊讶，因为到目前为止，我们还没有进行任何更改来减少对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，这是我们使用自定义比较器可以实现的。

让我们再次查看此运行的飞行记录：

屏幕截图于2015年1月22日的12.59.27