为什么flatMap（）之后的filter（）在Java流中“不完全”是惰性的？

Question

System.out.println(
       "Result: " +
        Stream.of(1, 2, 3)
                .filter(i -> {
                    System.out.println(i);
                    return true;
                })
                .findFirst()
                .get()
);
System.out.println("-----------");
System.out.println(
       "Result: " +
        Stream.of(1, 2, 3)
                .flatMap(i -> Stream.of(i - 1, i, i + 1))
                .flatMap(i -> Stream.of(i - 1, i, i + 1))
                .filter(i -> {
                    System.out.println(i);
                    return true;
                })
                .findFirst()
                .get()
);

1
Result: 1
-----------
-1
0
1
0
1
2
1
2
3
Result: -1

Answer 1

TL；DR，这个问题在JDK-8075939中得到了解决，并在Java10中得到了修正（并在JDK-8225328中被移植到Java8中）。

在研究实现时(referencePipeline.java)，我们看到方法[link]

@Override
final void forEachWithCancel(Spliterator<P_OUT> spliterator, Sink<P_OUT> sink) {
    do { } while (!sink.cancellationRequested() && spliterator.tryAdvance(sink));
}

它将在findfirst操作中调用。需要特别注意的是sink.cancellationRequested()，它允许在第一个匹配时结束循环。与[链接]相比较

@Override
public final <R> Stream<R> flatMap(Function<? super P_OUT, ? extends Stream<? extends R>> mapper) {
    Objects.requireNonNull(mapper);
    // We can do better than this, by polling cancellationRequested when stream is infinite
    return new StatelessOp<P_OUT, R>(this, StreamShape.REFERENCE,
                                 StreamOpFlag.NOT_SORTED | StreamOpFlag.NOT_DISTINCT | StreamOpFlag.NOT_SIZED) {
        @Override
        Sink<P_OUT> opWrapSink(int flags, Sink<R> sink) {
            return new Sink.ChainedReference<P_OUT, R>(sink) {
                @Override
                public void begin(long size) {
                    downstream.begin(-1);
                }

                @Override
                public void accept(P_OUT u) {
                    try (Stream<? extends R> result = mapper.apply(u)) {
                        // We can do better that this too; optimize for depth=0 case and just grab spliterator and forEach it
                        if (result != null)
                            result.sequential().forEach(downstream);
                    }
                }
            };
        }
    };
}

为了说明其中的含义，当stream.iterate(0,i->i+1).findfirst()按预期工作时，stream.of("“）.flatmap(x->stream.iterate(0,i->i+1)).findfirst()将陷入无限循环。

关于规范，大部分可以在

包规范的“流操作和管道”章节：

…

…懒惰还允许在不必要的时候避免检查所有的数据；对于诸如“查找第一个长度超过1000个字符的字符串”之类的操作，只需要检查足够多的字符串就可以找到一个具有所需特征的字符串，而无需检查源中所有可用的字符串。（当输入流是无限的而不仅仅是大的时，这种行为变得更加重要。）

…