JAVA8之数据流Stream

　　在JAVA8之前的传统编程方式，如果我们需要操作一个集合数据，需要使用集合提供的API，通过一个循环去获取集合的元素，这种访问数据的方式会使代码显得臃肿，JAVA8新引入的Stream类，用于重新封装集合数据，通过使用流式Stream代替常用集合数组、list和map的遍历操作可以极大的提高效率。

一、Stream的组成

数据源（Source） + 0个或多个中间操作(intermediate operation)和终止操作(terminal operation)

数据源：数据源头，可为数组、Collection、I/O资源和生成函数

二、构造流（Stream）

Arrays构造流

public static <T> Stream<T> stream(T[] array, int startInclusive, int endExclusive) {
        return StreamSupport.stream(spliterator(array, startInclusive, endExclusive), false);
}

由源码可知Arrays类由传入的数组生成一个Stream是委托StreamSupport来构建的，下面看下StreamSupport的源码

public static <T> Stream<T> stream(Spliterator<T> spliterator, boolean parallel) {
        Objects.requireNonNull(spliterator);
        return new ReferencePipeline.Head<>(spliterator,
                                            StreamOpFlag.fromCharacteristics(spliterator),
                                            parallel);
}

StreamSupport首先对spliterator参数进行判空，然后把它作为参数通过调用ReferencePipeline的内部类Head的构造函数生成一个ReferencePipeline.Head实例返回，通过对Head类源码的阅读可知他是ReferencePipeline的一个内部子类

static class Head<E_IN, E_OUT> extends ReferencePipeline<E_IN, E_OUT> {

        Head(Spliterator<?> source,
             int sourceFlags, boolean parallel) {
            super(source, sourceFlags, parallel);
        }

}

ReferencePipeline(Spliterator<?> source,
                      int sourceFlags, boolean parallel) {
        super(source, sourceFlags, parallel);
}
AbstractPipeline(Spliterator<?> source,
                     int sourceFlags, boolean parallel) {
        this.previousStage = null;
        this.sourceSpliterator = source;
        this.sourceStage = this;
        this.sourceOrOpFlags = sourceFlags & StreamOpFlag.STREAM_MASK;
        // The following is an optimization of:
        // StreamOpFlag.combineOpFlags(sourceOrOpFlags, StreamOpFlag.INITIAL_OPS_VALUE);
        this.combinedFlags = (~(sourceOrOpFlags << 1)) & StreamOpFlag.INITIAL_OPS_VALUE;
        this.depth = 0;
        this.parallel = parallel;
}

Head构造函数内部调用父类ReferencePipeline的构造函数,而ReferencePipeline的构造函数则调用父类AbstractPipeline构造函数最终完成Stream的构建，阅读源码我们可知构造流的核心是Spliterator，而最初持有他的是AbstractPipeline，现在我们来看下Spliterator接口

下面是源码对Spliterator的注释

/*
* An object for traversing and partitioning elements of a source.  The source
* of elements covered by a Spliterator could be, for example, an array, a
* {@link Collection}, an IO channel, or a generator function.
**/

翻译过来的意思是该接口是用于对数据源进行遍历和分区，即Spliterator对象封装了对数据源和分区的能力，接口声明的方法如下：

tryAdvance - 单元素遍历

trySplit - 分区抽象

forEachRemaining - 批量遍历

Stream - 实现原理

estimateSize - 默认实现，返回估计的大小

getExactSizeIfKnown - 默认实现，返回元素集合的确切大小

characteristics - 默认实现，返回当前spliterator源数据的一组特征值

hasCharacteristics - 默认实现，是否源数据是否包含该特征值

getComparator - 默认实现，如果该Spliterator操作的数据源是有序的，那么返回他的Comparator

好了，现在我们基本清楚Spliterator的作用和他在流中的定位，现在让我们回过头看下Arrays根据数组构造Stream流的JDK源码，深入到AbstractPipeline我们可以看到，Stream构造流是通过委托StreamSupport实现的，而核心是构建一个ArraySpliterator对象，可见，构造流(Stream)的核心就是构造一个Spliterator

Collection构造流

由上述对Arrays构造流分析可知构建流的核心是Spliterator，我们直接查看JAVA8中Collection构造流源码

 default Spliterator<E> spliterator() {
    return Spliterators.spliterator(this, 0);
 }
 default Stream<E> stream() {
    return StreamSupport.stream(spliterator(), false);
 }

Collection容器构造流与Arrays一样也是委托StreamSupport，代码设计的好的一点是他的流构建是在接口层面实现的，通过把他自身作为参数传入返回一个返回了一个IteratorSpliterator对象，不同集合的返回的IteratorSpliterator对象的tryAdvance等遍历方法不同，具体到IteratorSpliterator源码如下

        @Override
        public boolean tryAdvance(Consumer<? super T> action) {
            if (action == null) throw new NullPointerException();
            if (it == null) {
                it = collection.iterator();
                est = (long) collection.size();
            }
            if (it.hasNext()) {
                action.accept(it.next());
                return true;
            }
            return false;
        }    

可知IteratorSpliterator对源码的遍历处理是通过传入一个Consumer消费函数消费不同Collection实现类Iterator迭代器获取的元素实现，感谢JAVA8接口的default设计。

三、Stream常用方法列表

Stream中间操作方法列表

方法	参数	用途
concat	Stream< ? extends T> a, Stream< ? extends T> b	将两个流合起来形成新流
distinct		将流里的元素按照Ojbect.equal方法进行聚合去重，返回一个去重结果的新流
empty		返回一个空的流
filter	Predicate< ? super T> predicate	按照谓词参数predicate过滤，返回过滤后的流Stream
flatMap	Function< ? super T, ? extends Stream< ? extends R>> mapper	将流里的元素T，按照参数Function进行处理，处理结果是一个子流Stream< ? extends R>，后续将子流flat打平，形成元素R的新流。类似的有flatToDouble、flatToInt和flatToLong
limit	long maxSize	返回一个新流，只包含maxSize个元素，其他被truncate掉
map	Function< ? super T, ? extends R> mapper	经典的map操作，对流里的每个元素，通过参数mapper映射为一个新的元素，返回新元素的流。类似map有mapToDouble、mapToInt和mapToLong
peek	Consumer< ? super T> action	这个动作非常有趣，它并不改变流，而是对流里的每个元素执行一个Consumer，对其进行一次处理。原始流不变继续返回
skip	long n	跳过n个元素，从第n+1个元素开始返回一个新的流
sorted	Comparator< ? super T> comparator	根据参数排序器对流进行排序，返回新的流。如果参数为空，则按照自然序排

Stream终止操作方法列表

方法	参数	用途
allMatch	Predicate< ? super T> predicate	根据谓词函数判断流里的元素是否都满足，返回对应的boolean值
anyMatch	Predicate< ? super T> predicate	根据谓词函数判断流里的元素是否存在一个或多个满足，返回对应的boolean值
noneMatch	Predicate< ? super T> predicate	根据谓词函数判断流里的元素是否不存在任何一个元素满足，返回对应的boolean值
count		返回这个流里元素的个数
findAny		返回一个Optional对象，这个等价于对于一个流执行一个select操作，返回一条记录
findFirst		返回这个流里的第一个元素的Optional，如果这个流不是有序的，则返回任意元素
forEach	Consumer< ? super T> action	对这个流的每个元素，执行参数Consumer
forEachOrdered	Consumer<? super T> action	针对forEach在并行流里对有序元素的输出不足，这个方法确保并行流中按照原来顺序处理
max	Comparator<? super T> comparator	返回一个Optional值，包含了流里元素的max，条件是按照参数排序器排序
min	Comparator<? super T> comparator	返回一个Optional值，包含了流里元素的min，条件是按照参数排序器排序
reduce	BinaryOperator< T> accumulator	经典的reduce，就是根据一个二元操作算子，将流中的元素逐个累计操作一遍，初始元素以foundAny结果为主
reduce	T identity, BinaryOperator< T> accumulator	与上面的方法一致，只不过多了一个初始值，不需要findAny了
reduce	U identity,BiFunction< U, ? super T, U> accumulator,BinaryOperator< U> combiner	最复杂的reduce，看到combiner会不会有联想？它做的也是对于一个流里的元素T，使用二元函数accumulator计算，计算的值累计到U上，因为之前的reduce要求流元素和结果元素类型一致，所以有限制。而该reduce函数，支持T和U类型不同，通过二元函数转换，但是要求combiner会执行这个事情，要求“ combiner.apply(u, accumulator.apply(identity, t)) == accumulator.apply(u, t)”
collect	Supplier< R> supplier,BiConsumer< R, ? super T> accumulator,BiConsumer< R, R> combiner	超级强大的方法。常规的reduce是返回不可变的值。而collect可以将reduce后的值升级为一个可变容器。具体这个方法就是对流里每个元素T，将Supplier提供的值R作为初始值，用BiConsumer的accumulator进行累加计算。combiner的作用和要求和reduce是一样的
collect	Collector< ? super T, A, R> collector	和上面的collect一致，只不过Collector封装了一组上面的参数，T是流里的元素，A是累计中间结果，R是返回值的类型（collect的话就是容器了）

四、Stream工作原理

下面我们分析下Stream的工作原理

        Integer[] array = new Integer[]{1,2,3,4};
        Optional<Integer> result =  Stream.of(array).filter(v -> v > 2).sorted((v1, v2) -> v2.compareTo(v1)).limit(2).reduce((v1, v2) -> v1 + v2);

        System.out.println(result.get());

　　首先调用Stream.of方法根据一个Integer对象数组构建了流，函数内部是通过调用Arrays.stream方法返回流，对应的Spliterator实现是ArraySpliterator,然后调用filter方法过滤，我们分析下这个阶段对应的源码

    @Override
    public final Stream<P_OUT> filter(Predicate<? super P_OUT> predicate) {
        Objects.requireNonNull(predicate);
        return new StatelessOp<P_OUT, P_OUT>(this, StreamShape.REFERENCE,
                                     StreamOpFlag.NOT_SIZED) {
            @Override
            Sink<P_OUT> opWrapSink(int flags, Sink<P_OUT> sink) {
                return new Sink.ChainedReference<P_OUT, P_OUT>(sink) {
                    @Override
                    public void begin(long size) {
                        downstream.begin(-1);
                    }

                    @Override
                    public void accept(P_OUT u) {
                        if (predicate.test(u))
                            downstream.accept(u);
                    }
                };
            }
        };
    }

由源码可知filter把前面构造的流（Stream）本身作为参数返回了一个StatelessOp实现对象，深入StatelessOp类我们知道它是ReferencePipeline的一个内部类，继承ReferencePipeline，而上面我们分析过ReferencePipeline继承自AbstractPipeline，回到filter源码，我们看到在filter方法里面实现了超类AbstractPipeline的OpWrapSink方法

    /**
     * Accepts a {@code Sink} which will receive the results of this operation,
     * and return a {@code Sink} which accepts elements of the input type of
     * this operation and which performs the operation, passing the results to
     * the provided {@code Sink}.
     *
     * @apiNote
     * The implementation may use the {@code flags} parameter to optimize the
     * sink wrapping.  For example, if the input is already {@code DISTINCT},
     * the implementation for the {@code Stream#distinct()} method could just
     * return the sink it was passed.
     *
     * @param flags The combined stream and operation flags up to, but not
     *        including, this operation
     * @param sink sink to which elements should be sent after processing
     * @return a sink which accepts elements, perform the operation upon
     *         each element, and passes the results (if any) to the provided
     *         {@code Sink}.
     */
    abstract Sink<E_IN> opWrapSink(int flags, Sink<E_OUT> sink);

ChainedReference.java源码

/**
     * Abstract {@code Sink} implementation for creating chains of
     * sinks.  The {@code begin}, {@code end}, and
     * {@code cancellationRequested} methods are wired to chain to the
     * downstream {@code Sink}.  This implementation takes a downstream
     * {@code Sink} of unknown input shape and produces a {@code Sink<T>}.  The
     * implementation of the {@code accept()} method must call the correct
     * {@code accept()} method on the downstream {@code Sink}.
     */
    static abstract class ChainedReference<T, E_OUT> implements Sink<T> {
        protected final Sink<? super E_OUT> downstream;

        public ChainedReference(Sink<? super E_OUT> downstream) {
            this.downstream = Objects.requireNonNull(downstream);
        }

        @Override
        public void begin(long size) {
            downstream.begin(size);
        }

        @Override
        public void end() {
            downstream.end();
        }

        @Override
        public boolean cancellationRequested() {
            return downstream.cancellationRequested();
        }
    }

通过对上述源码的分析可知Sink（Consumer的一个派生类）在流中的作用其实是用于控制流中间阶段的数据、大小等状态信息，在Sink方法中还定义了两个方法，begin和end，begin在Sink的accept方法之前调用，end在accept方法之后调用，主要是用于对流程数据进行一些额外的控制，现在我们在结合分析filter源码发现，为了维护支持流（Stream）的中间操作状态信息，JAVA8流在结构上其实被设计成一个链表结构，一个Head起始节点，多个中间节点StatelessMap(继承自ReferencePipeline)，而流程中管理和控制数据状态信息的实际是其中的Sink。

　　接下来是到sorted排序阶段，我们继续深入源码。

ReferencePipeline.java

@Override
    public final Stream<P_OUT> sorted(Comparator<? super P_OUT> comparator) {
        return SortedOps.makeRef(this, comparator);
}

SortedOps.java

    static <T> Stream<T> makeRef(AbstractPipeline<?, T, ?> upstream,
                                Comparator<? super T> comparator) {
        return new OfRef<>(upstream, comparator);
    }

排序是一个有状态的中间操作，与filter阶段类似sorted方法实际返回的是一个OfRef对象，深入SortedOps的makeRef方法，可知返回了一个OfRef实例分析该类可知该类是StatefulOp的子类，该类持有一个排序器，解读StatefulOp类源码可知该类是流中间状态的基类，对比StatelessOp类，接下来通过源码分析方法的逻辑

SortedOps.OfRef

        @Override
        public Sink<T> opWrapSink(int flags, Sink<T> sink) {
            Objects.requireNonNull(sink);

            // If the input is already naturally sorted and this operation
            // also naturally sorted then this is a no-op
            if (StreamOpFlag.SORTED.isKnown(flags) && isNaturalSort)
                return sink;
            else if (StreamOpFlag.SIZED.isKnown(flags))
                return new SizedRefSortingSink<>(sink, comparator);
            else
                return new RefSortingSink<>(sink, comparator);
        }

分析代码可知实现逻辑与filter阶段类似，都是通过Sink控制流的数据和中间状态信息，流程逻辑是先对入参Sink判空，如果流有序，直接返回sink，否则判断是否有界，如果有界返回一个SizedRefSortingSink对象，否则返回一个RefSortingSink对象，深入两个类，不出意外，前者内部是通过数组保存数据，后者是通过一个ArrayList实例保存，两者均是在end方法里借由内部排序器完成元素排序

　　接下来的limit截取阶段类似，读者可自行分析，大体的实现逻辑与上述两个阶段并无二致

　　最后到了终止操作阶段reduce

ReferencePipeline.java

    @Override
    public final Optional<P_OUT> reduce(BinaryOperator<P_OUT> accumulator) {
        return evaluate(ReduceOps.makeRef(accumulator));
    }

AbstractPipeline.java

    final <R> R evaluate(TerminalOp<E_OUT, R> terminalOp) {
        assert getOutputShape() == terminalOp.inputShape();
        if (linkedOrConsumed)
            throw new IllegalStateException(MSG_STREAM_LINKED);
        linkedOrConsumed = true;

        return isParallel()
               ? terminalOp.evaluateParallel(this, sourceSpliterator(terminalOp.getOpFlags()))
               : terminalOp.evaluateSequential(this, sourceSpliterator(terminalOp.getOpFlags()));
    }

ReduceOps.java

        @Override
        public <P_IN> R evaluateSequential(PipelineHelper<T> helper,
                                           Spliterator<P_IN> spliterator) {
            return helper.wrapAndCopyInto(makeSink(), spliterator).get();
        }

AbstractPipeline.java

    @Override
    final <P_IN, S extends Sink<E_OUT>> S wrapAndCopyInto(S sink, Spliterator<P_IN> spliterator) {
        copyInto(wrapSink(Objects.requireNonNull(sink)), spliterator);
        return sink;
    }

    @Override
    final <P_IN> void copyInto(Sink<P_IN> wrappedSink, Spliterator<P_IN> spliterator) {
        Objects.requireNonNull(wrappedSink);

        if (!StreamOpFlag.SHORT_CIRCUIT.isKnown(getStreamAndOpFlags())) {
            wrappedSink.begin(spliterator.getExactSizeIfKnown());
            spliterator.forEachRemaining(wrappedSink);
            wrappedSink.end();
        }
        else {
            copyIntoWithCancel(wrappedSink, spliterator);
        }
    }

通过对源码的分析可知，在Stream的中间阶段如果没有意外中断，代码执行到终止操作时才开始执行前面定义的各个中间操作，也就是说Stream的中间操作的执行方式都是lazy，读者可自行在中间流的opWrapSink打断点，去掉流的终止操作进行校验。