大佬教程收集整理的这篇文章主要介绍了Java Lambdas比匿名类慢20倍，大佬教程大佬觉得挺不错的，现在分享给大家，也给大家做个参考。
您显然会遇到lambda表达式的首次初始化开销。正如评论中已经提到的那样，lambda表达式的类是在运行时生成的，而不是从类路径中加载的。
但是，生成并不是导致速度下降的原因。毕竟，生成具有简单结构的类甚至比从外部源加载相同的字节还要快。而且内部类也必须加载。但是，当应用程序以前未使用过lambda表达式时，甚至必须加载用于生成lambda类的框架（@R_801_10353@le当前的实现在后台使用ASM）。这是导致十二个内部使用的类（而不是lambda表达式本身）变慢，加载和初始化的实际原因。
您可以轻松地验证这一点。在当前使用lambda表达式的代码中，您有两个相同的表达式(i1, i2) ->
Integer.compare(i1.start,
i2.start)。当前的实现无法识别这一点（实际上，编译器也未提供任何提示）。因此，这里生成了两个甚至具有不同类的lambda实例。您可以将代码重构为只有一个比较器，类似于内部类的变体：
final Comparator<? super Interval> comparator
= (i1, i2) -> Integer.compare(i1.start, i2.start);
int start = Collections.binarySearch(intervals, newInterval, comparator);
int skip = start >= 0 ? start : -start - 1;
int end = Collections.binarySearch(intervals.subList(skip, intervals.size()),
new Interval(newInterval.end, 0),
comparator);
您不会注意到任何显着的性能差异，因为无关紧要的是lambda表达式的数量，而仅仅是框架的类加载和初始化（仅发生一次）。
您甚至可以通过插入其他lambda表达式（例如
final Comparator<? super Interval> comparator1
= (i1, i2) -> Integer.compare(i1.start, i2.start);
final Comparator<? super Interval> comparator2
= (i1, i2) -> Integer.compare(i1.start, i2.start);
final Comparator<? super Interval> comparator3
= (i1, i2) -> Integer.compare(i1.start, i2.start);
final Comparator<? super Interval> comparator4
= (i1, i2) -> Integer.compare(i1.start, i2.start);
final Comparator<? super Interval> comparator5
= (i1, i2) -> Integer.compare(i1.start, i2.start);
没有看到任何放缓。这实际上是您在此处注意到的整个运行时的第一个lambda表达式的初始开销。由于Leetcode本身在输入代码之前显然不使用lambda表达式，因此执行时间会被测量，因此此开销会增加您的执行时间。
我在这里看到了很多有关Java Lambda性能的问题，但大多数问题都像“ Lambda稍快，但使用闭包时变慢”或“预热与执行时间不同”或其他类似的问题。
但是，我在这里碰到了一件很奇怪的事情。考虑这个LeetCode问题：
这个问题被贴上了标签，所以我认为线性方法不是他们想要的。因此，我决定想出一种巧妙的方法，将二进制搜索与对输入列表的修改相结合。现在，在修改输入列表时，问题还不是很清楚，即使签名需要返回对列表的引用，它也显示为“插入”，但现在不要紧。这是完整的代码，但是只有前几行与此问题相关。我将其余的保留在这里，以便任何人都可以尝试：
public List<Interval> insert(List<Interval> intervals,Interval newInterval) {
int start = Collections.binarySearch(intervals,newInterval,(i1,i2) -> Integer.compare(i1.start,i2.start));
int skip = start >= 0 ? start : -start - 1;
int end = Collections.binarySearch(intervals.subList(skip,intervals.size()),new Interval(newInterval.end,0),i2.start));
if (end >= 0) {
end += skip; // BACk to original indexes
} else {
end -= skip; // ditto
}
int newStart = newInterval.start;
int headEnd;
if (-start - 2 >= 0) {
Interval prev = intervals.get(-start - 2);
if (prev.end < newInterval.start) {
// the new interval doesn't overlap the one before the insertion point
headEnd = -start - 1;
} else {
newStart = prev.start;
headEnd = -start - 2;
}
} else if (start >= 0) {
// merge the first interval
headEnd = start;
} else { // start == -1,insertion point = 0
headEnd = 0;
}
int newEnd = newInterval.end;
int tailStart;
if (-end - 2 >= 0) {
// merge the end with the previous interval
newEnd = Math.max(newEnd,intervals.get(-end - 2).end);
tailStart = -end - 1;
} else if (end >= 0) {
newEnd = intervals.get(end).end;
tailStart = end + 1;
} else { // end == -1,insertion point = 0
tailStart = 0;
}
intervals.subList(headEnd,tailStart).clear();
intervals.add(headEnd,new Interval(newStart,newEnd));
return intervals;
}
这种方法运行良好并被接受，但运行时为80毫秒，而大多数解决方案为4-5毫秒和18-19毫秒。当我查找它们时，它们都是线性的并且非常原始。人们不会期望从标记为“困难”的问题中得到期望。
但是问题来了：在最坏的情况下，我的解决方案也是线性的（因为添加/清除操作是线性时间）。为什么 这么 慢？然后我这样做了：
Comparator<Interval> comparator = new Comparator<Interval>() {
@Override
public int compare(Interval i1,Interval i2) {
return Integer.compare(i1.start,i2.start);
}
};
int start = Collections.binarySearch(intervals,comparator);
int skip = start >= 0 ? start : -start - 1;
int end = Collections.binarySearch(intervals.subList(skip,comparator);
从80毫秒降低到4毫秒！这里发生了什么？不幸的是，我不知道LeetCode在什么样的环境下运行什么样的测试，但是仍然不是20倍吗？
以上是大佬教程为你收集整理的Java Lambdas比匿名类慢20倍全部内容，希望文章能够帮你解决Java Lambdas比匿名类慢20倍所遇到的程序开发问题。
如果觉得大佬教程网站内容还不错，欢迎将大佬教程推荐给程序员好友。
本图文内容来源于网友网络收集整理提供，作为学习参考使用，版权属于原作者。
如您有任何意见或建议可联系处理。小编QQ：384754419，请注明来意。