在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打断点，去掉流的终止操作进行校验。
