Java 8 流管道性能

Question

我对在 java-08 中使用 Stream API 的性能增强有一些疑问。 以下是java-06中的代码。

int sum = 0;
    for (int x : numbers) {
       sum += x;
    }

这是java-8中的代码。

 int sum = numbers.stream().reduce(0, (x,y) -> x+y);

或：

int sum = numbers.stream().reduce(0, Integer::sum);

问题：- 虽然两个代码中的行数相同，但内部操作是如何进行的？ 这就是它转换为流和并行处理的方式。

Answer 1

首先，您的流不是并行流。您必须明确调用 List#parallelStream 或 Stream#parallel。例如：

int sum = numbers.parallelStream().reduce(0, Integer::sum);

另一种求和numbers 的方法是将Stream<Integer> 映射到IntStream，它会取消装箱N 次，但Stream#reduce 会取消装箱2 *(N - 1) 次，如果流大小> 2、例如：

int sum = numbers.parallelStream().mapToInt(Integer::intValue).sum();

对于“内部运行情况如何？”，你可以看Eran的回答，据我所知他已经详细描述了并行流。 p>

Stream#reduce 拆箱

1 + 2 + 3 + 4 + 5减少树的例子如下，拆箱操作次数：N = 10（1(2) + 5(2) + 9(2) + 6(2) + 15(2)）：

// v--- identity
   0      1     2       3     4       5
     1(2)          5(2)          9(2)
            6(2)          9(/)
                  15(2) 
//                ^  ^--- unboxing times, `/` means doesn't reducing at this time
//                |
//                |---  the sum result of current reducing  

Answer 2

.reduce(0, (x,y) -> x+y) 和 .reduce(0, Integer::sum) 之间没有性能差异。差异在编译时处理：

对于 lambda 表达式，将生成一个包含 lambda 主体的合成方法，x+y。相比之下，Integer::sum 指的是现有方法，其代码完全相同。从那时起，发生的一切都将是一样的。您的类将请求 JRE 生成功能接口的实现，其功能方法将调用指定的方法、合成方法或现有方法，两者都做同样的事情。

因此，无论哪种情况，您最终都会得到一个 JRE 生成的 BinaryOperator，它将调用一个返回两个 int 参数之和的方法。由于没有技术差异，因此不可能有任何性能差异。

但作为holi-java correctly pointed out，两种变体都包含不必要的装箱开销。 BinaryOperator<Integer> 接收两个 Integer 实例，如果两者都是现有的实例，这很好，源于集合，但也会返回一个 Integer，这将是输入总和的盒装表示。该总和可能会被传递到 BinaryOperator<Integer> 的下一次评估中，再次被拆箱。

相比之下，

int sum = numbers.stream().mapToInt(Integer::intValue).sum();

只需要从集合中拆箱，但永远不会再装箱或拆箱中间总和。请注意，在使用 parallelStream() 而不是 stream() 之前，您需要相当多的元素。