Java8-Lambda编程[6] 总结与放弃

填坑
先来填坑，不知你们还记得我在第五章《串行与并行》中留的坑吗？下面咱们就来继续挖它，经过剖析源码，一层一层拨开它的心。

万流之眼 StreamSupport辅助类

　　为何只是将parallel标志位设为false或true就能够关闭或开启并行，真正的实现原理是什么呢？咱们先来看看集合类的stream方法与parallelStream方法有什么不一样，结果可能使人哑然失笑。

//Collection接口中的默认实现
default Stream<E> stream() {

return StreamSupport.stream(spliterator(), false);

}
default Stream<E> parallelStream() {

return StreamSupport.stream(spliterator(), true);

}
　　这两个方法都是像咱们以前使用Spliterator的时候那样，直接调用了StreamSupport的stream方法，区别只在于最后的并行标志位。相似的代码也出如今了Stream类的of、iterate、generate等方法中，由此能够推断，StreamSupport的stream方法就是是系统类库中产生流的惟一方法，固然这里说的流不包括基本类型流。

追本溯源 Pipeline世家

　　StreamSupport的stream方法返回了一个ReferencePipeline.Head对象。ReferencePipeline是个抽象类，继承了AbstractPipeline，并实现了其中大多数的方法，而Head是ReferencePipeline的内部类，继承了ReferencePipeline并实现了剩下的两个方法。总结一下就是Head内部类继承了ReferencePipeline抽象类继承了AbstractPipeline抽象类实现了Stream接口，因此Head就是咱们最后获得的Stream。

最终实现 Head内部类

　　Head中对ReferencePipeline留下的两个没有实现的方法的实现看起来很古怪，都是直接抛出了UnsupportedOperationException,表示不支持该操做。咱们也不用关注这些，而是把注意力放在它重写的另外两个方法上，名字你们都很熟悉，forEach和forEachOrdered。这两个方法的重写也很简单，以forEach为例：

if (!isParallel()) {
        sourceStageSpliterator().forEachRemaining(action);
    }
    else {
        super.forEach(action);
    }

　　该方法仅仅只是判断一下isParallel，若是是并行的就仍是调父类的方法，不然就调用Spliterator的forEachRemaining方法，该方法在Spliterator接口中有默认的实现，只有一行代码：

do { } while (tryAdvance(action));

　　是否是很绝，什么也不作，等到tryAdvance返回false就结束。tryAdvance咱们前面已经讲到，是用来判断分割式迭代是否结束的。也就是说，若是流是串行的，就不会进行分割，这时候Spliterator就变成了普通的迭代器，从头至尾逐个进行操做。

命令执行 TerminalOp众子

　　对于并行流，Head则会调用父类ReferencePipeline中的同名方法，该方法中又会调用evaluate方法，根据不一样的行为如forEach、reduce来选择执行不一样的操做。全部的操做类都要实现TerminalOp接口，如forEach操做就对应着ForEachOp类,reduce操做对应着ReduceOp类,这些操做会做为参数传给evaluate方法。evaluate方法最后仍是会根据isParallel来选择执行并行操做仍是串行操做，两类操做分别对应着须要重写的evaluateParallel方法与evaluateSequentia方法（evaluateParallel有默认实现），两个方法均由操做类来实现，而且都须要传递一个Spliterator参数。

幕后核心 Spliterator接口

　　无论并行流仍是串行流，函数调用的过程当中，都无一例外的须要传递一个Spliterator参数。第一次看到这里的时候我以为很玄，不少时候系统给你提供个类，你不去用，到头来看源码却发现发现原来它才是万物起源。这后面的事情，百川归海，我就不一一细说了，有兴趣的读者能够自行探索。