Java 8的流：为什么并行流比较慢？

Question

我正在使用Java 8的流，无法理解我得到的性能结果。我有2个核心CPU（Intel i73520M），Windows 8 x64和64位Java 8 Update5。我正在对String的流/并行流进行简单映射，发现并行版本要慢一些。

Function<Stream<String>, Long> timeOperation = (Stream<String> stream) -> {

  long time1 = System.nanoTime();

  final List<String> list = 

     stream

       .map(String::toLowerCase)

       .collect(Collectors.toList());

  long time2 = System.nanoTime();

  return time2 - time1;

};

Consumer<Stream<String>> printTime = stream ->

  System.out.println(timeOperation.apply(stream) / 1000000f);

String[] array = new String[1000000];

Arrays.fill(array, "AbabagalamagA");

printTime.accept(Arrays.stream(array));            // prints around 600

printTime.accept(Arrays.stream(array).parallel()); // prints around 900

考虑到我有2个CPU内核，并行版本是否应该更快？有人可以提示我为什么并行版本比较慢吗？

Answer 1

确实有几个并行发生的问题。首先是并行解决问题始终比顺序执行涉及更多的实际工作。开销涉及将工作划分为多个线程，以及合并或合并结果。诸如将短字符串转换为小写字母之类的问题足够小，以至于它们有被并行拆分开销淹没的危险。第二个问题是，对Java程序进行基准测试非常微妙，并且很容易得出令人困惑的结果。两个常见问题是JIT编译和无效代码消除。简短的基准测试通常在JIT编译之前或期间完成，因此它们无法衡量峰值吞吐量，实际上它们可能是在衡量JIT本身。当编译发生时是不确定的，因此它也可能导致结果变化很大。对于小型综合基准，工作负载通常会计算被丢弃的结果。JIT编译器非常擅长检测到这一点，并消除了不会产生可在任何地方使用的结果的代码。在这种情况下可能不会发生这种情况，但是如果您修改其他综合工作负载，则肯定会发生。当然，如果JIT消除了基准测试工作量，它将使基准测试无用。我强烈建议您使用完善的基准测试框架（例如JMH），而不是手动编写一个自己的框架。JMH具有帮助避免常见基准测试陷阱（包括这些陷阱）的功能，并且很容易设置和运行。这是您转换为使用JMH的基准：package com.stackoverflow.questions;import java.util.Arrays;import java.util.List;import java.util.stream.Collectors;import java.util.concurrent.TimeUnit;import org.openjdk.jmh.annotations.*;public class SO23170832 {&nbsp; &nbsp; @State(Scope.Benchmark)&nbsp; &nbsp; public static class BenchmarkState {&nbsp; &nbsp; &nbsp; &nbsp; static String[] array;&nbsp; &nbsp; &nbsp; &nbsp; static {&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; array = new String[1000000];&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Arrays.fill(array, "AbabagalamagA");&nbsp; &nbsp; &nbsp; &nbsp; }&nbsp; &nbsp; }&nbsp; &nbsp; @GenerateMicroBenchmark&nbsp; &nbsp; @OutputTimeUnit(TimeUnit.SECONDS)&nbsp; &nbsp; public List<String> sequential(BenchmarkState state) {&nbsp; &nbsp; &nbsp; &nbsp; return&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Arrays.stream(state.array)&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; .map(x -> x.toLowerCase())&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; .collect(Collectors.toList());&nbsp; &nbsp; }&nbsp; &nbsp; @GenerateMicroBenchmark&nbsp; &nbsp; @OutputTimeUnit(TimeUnit.SECONDS)&nbsp; &nbsp; public List<String> parallel(BenchmarkState state) {&nbsp; &nbsp; &nbsp; &nbsp; return&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Arrays.stream(state.array)&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; .parallel()&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; .map(x -> x.toLowerCase())&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; .collect(Collectors.toList());&nbsp; &nbsp; }}我使用命令运行此命令：java -jar dist/microbenchmarks.jar ".*SO23170832.*" -wi 5 -i 5 -f 1（这些选项指示5个热身迭代，5个基准迭代和1个分叉的JVM。）在运行期间，JMH会发出很多详细消息，而我已经忽略了这些消息。总结结果如下。Benchmark&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;Mode&nbsp; &nbsp;Samples&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;Mean&nbsp; &nbsp;Mean error&nbsp; &nbsp; Unitsc.s.q.SO23170832.parallel&nbsp; &nbsp; &nbsp; thrpt&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;5&nbsp; &nbsp; &nbsp; &nbsp; 4.600&nbsp; &nbsp; &nbsp; &nbsp; 5.995&nbsp; &nbsp; ops/sc.s.q.SO23170832.sequential&nbsp; &nbsp; thrpt&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;5&nbsp; &nbsp; &nbsp; &nbsp; 1.500&nbsp; &nbsp; &nbsp; &nbsp; 1.727&nbsp; &nbsp; ops/s请注意，结果以每秒操作数为单位，因此看起来并行运行比顺序运行快约三倍。但是我的机器只有两个核心。嗯 而且每次运行的平均错误实际上大于平均运行时间！WAT？这里有些鱼腥味。这给我们带来了第三个问题。仔细观察工作负载，我们可以看到它为每个输入分配了一个新的String对象，并且还将结果收集到一个列表中，该列表涉及大量的重新分配和复制。我猜想这将导致大量垃圾回收。通过在启用了GC消息的情况下重新运行基准测试，我们可以看到以下内容：java -verbose:gc -jar dist/microbenchmarks.jar ".*SO23170832.*" -wi 5 -i 5 -f 1结果如下：[GC (Allocation Failure)&nbsp; 512K->432K(130560K), 0.0024130 secs][GC (Allocation Failure)&nbsp; 944K->520K(131072K), 0.0015740 secs][GC (Allocation Failure)&nbsp; 1544K->777K(131072K), 0.0032490 secs][GC (Allocation Failure)&nbsp; 1801K->1027K(132096K), 0.0023940 secs]# Run progress: 0.00% complete, ETA 00:00:20# VM invoker: /Users/src/jdk/jdk8-b132.jdk/Contents/Home/jre/bin/java# VM options: -verbose:gc# Fork: 1 of 1[GC (Allocation Failure)&nbsp; 512K->424K(130560K), 0.0015460 secs][GC (Allocation Failure)&nbsp; 933K->552K(131072K), 0.0014050 secs][GC (Allocation Failure)&nbsp; 1576K->850K(131072K), 0.0023050 secs][GC (Allocation Failure)&nbsp; 3075K->1561K(132096K), 0.0045140 secs][GC (Allocation Failure)&nbsp; 1874K->1059K(132096K), 0.0062330 secs]# Warmup: 5 iterations, 1 s each# Measurement: 5 iterations, 1 s each# Threads: 1 thread, will synchronize iterations# Benchmark mode: Throughput, ops/time# Benchmark: com.stackoverflow.questions.SO23170832.parallel# Warmup Iteration&nbsp; &nbsp;1: [GC (Allocation Failure)&nbsp; 7014K->5445K(132096K), 0.0184680 secs][GC (Allocation Failure)&nbsp; 7493K->6346K(135168K), 0.0068380 secs][GC (Allocation Failure)&nbsp; 10442K->8663K(135168K), 0.0155600 secs][GC (Allocation Failure)&nbsp; 12759K->11051K(139776K), 0.0148190 secs][GC (Allocation Failure)&nbsp; 18219K->15067K(140800K), 0.0241780 secs][GC (Allocation Failure)&nbsp; 22167K->19214K(145920K), 0.0208510 secs][GC (Allocation Failure)&nbsp; 29454K->25065K(147456K), 0.0333080 secs][GC (Allocation Failure)&nbsp; 35305K->30729K(153600K), 0.0376610 secs][GC (Allocation Failure)&nbsp; 46089K->39406K(154624K), 0.0406060 secs][GC (Allocation Failure)&nbsp; 54766K->48299K(164352K), 0.0550140 secs][GC (Allocation Failure)&nbsp; 71851K->62725K(165376K), 0.0612780 secs][GC (Allocation Failure)&nbsp; 86277K->74864K(184320K), 0.0649210 secs][GC (Allocation Failure)&nbsp; 111216K->94203K(185856K), 0.0875710 secs][GC (Allocation Failure)&nbsp; 130555K->114932K(199680K), 0.1030540 secs][GC (Allocation Failure)&nbsp; 162548K->141952K(203264K), 0.1315720 secs][Full GC (Ergonomics)&nbsp; 141952K->59696K(159232K), 0.5150890 secs][GC (Allocation Failure)&nbsp; 105613K->85547K(184832K), 0.0738530 secs]1.183 ops/s注意：以开头的行#是正常的JMH输出线。其余所有都是GC消息。这只是五个预热迭代中的第一个，它先于五个基准迭代。在其余的迭代过程中，GC消息以相同的方式继续传递。我认为可以肯定地说，测得的性能主要由GC开销决定，不应相信报告的结果。目前尚不清楚该怎么做。这纯粹是综合性的工作量。显然，与分配和复制相比，完成实际工作只需要很少的CPU时间。很难说您真正想在这里衡量什么。一种方法是提出在某种意义上更“真实”的不同工作负载。另一种方法是更改堆和GC参数，以避免在基准测试运行期间出现GC。