第 7 章并行数据处理与性能

笔记来源：《Java实战（第2版）》ISBN:978-7-115-52148-4 作者：拉乌尔·加布里埃尔·乌尔玛,马里奥·富斯科,艾伦·米克罗夫特.

7.1 并行流

并行流就是把内容拆分成多个数据块，用不同线程分别处理每个数据块的流

对顺序流调用 parallel 方法

1
2
3
  public static long parallelSum(long n) {
    return Stream.iterate(1L, i -> i + 1).limit(n).parallel().reduce(Long::sum).get();
  }

配置并行流使用的线程池

并行流内部使用了默认的 ForkJoinPool
默认线程数量就是处理器数量
这个值由 Runtime.getRuntime().availableProcessors() 得到的
可以通过系统属性 System.setProperty(“java.util.concurrent.ForkJoinPool.common.parallelism”, “12”);
- Java 11 这个方法已经失效
- 没有充足的理由，强烈建议不要修改

JMH （Java 微基准套件 Java microbenchmark harness）

Stream.iterate 本质上是顺序的，使用它的并行流，性能提升不明显

1
2
3
  public long sequentialSum() {
    return Stream.iterate(1L, i -> i + 1).limit(N).reduce(0L, Long::sum);
  }

选择适当的数据结构往往比并行化算法更重要

1
2
3
  public long parallelRangedSum() {
    return LongStream.rangeClosed(1, N).parallel().reduce(0L, Long::sum);
  }

并行化的代价

通过测量，判断是否得到性能提升
留意装箱，原始类型流：IntStream、LongStream、DoubleStream
有些操作本身在并行流上的性能就比顺序流差
- limit、findFirst 等医疗元素顺序的操作
- findAny 不需要按顺序操作，性能优于 findFirst
- 调用 unordered 方法把有序流变成无序流
考虑流的操作流水线的总计算成本
对于较小的数据量，选择并行几乎是一个糟糕的决定
要考虑流背后的数据结构是否易于分解
- ArrayList 的拆分效率比 LinkedList 高的多，因为前者不用遍历就可以平均拆分，后者则必须遍历
- 用 range 工厂方法创建的原始类型流也可以快速分解
流自身的特点以及流水线中的中间操作修改流的方式，都可能会改变分解过程的性能
还要考虑终端操作中合并步骤的代价的大小

对一个任务调用 join 方法会阻塞调用方，直到该任务返回结果
- 有必要在两个子任务的计算都开始之后再调用
- 否则，你的代码会比原始的顺序算法更慢且更复杂，因为每个子任务都必须等待另一个子任务完成后才能启动
不应该在 RecursiveTask 内部使用 ForkJoinPool 的 invoke 方法
对子任务调用 fork 方法可以把它排进 ForkJoinPool
- 同时对左右两边的子任务调用它似乎很自然，但这样的效率比直接对期中一个调用 compute 低
- 这样做可以为期中一个子任务重用同一线程，从而避免在线程池中多分配一个任务造成的开销
Debug 时会很郁闷
和并行流一样，不一定比顺序执行速度快
- 一个惯用的方法：把输入/输出放在一个子任务，计算放在另一个，这样计算就可以和输入/输出同时进行

由于每个任务花费的时间不同（比如磁盘、网络访问慢），导致有的线程很闲、有的很忙，为了平衡工作量，有了工作窃取算法