为什么 Java Streams 中的'filter()”在'flatMap()”之后显得不那么懒惰？

为什么在 Java Streams 中，filter() 在 flatMap() 之后不是“完全”惰性的？

在 Java 8 流中，中间操作如filter() 和 flatMap() 是惰性的，这意味着它们在调用像 findFirst() 这样的终端操作之前不会执行。然而，当 filter() 跟随 flatMap() 时，这种惰性并没有完全实现，从而导致意外的行为。

考虑这个代码示例：

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

输出显示只有第一个打印了元素，表明filter()是懒惰的，并且在满足条件时短路。相比之下：

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();

令人惊讶的是，所有元素都被打印出来。即使 filter() 立即满足其条件，它也会继续处理流的后续元素。

原因

此行为是由于 Java Streams 实现造成的。在 flatMap() 之后，流不再包含原始元素。相反，它包含由 flatMap() 生成的一系列扁平化元素。当filter()跟随时，它对这些扁平化的元素进行操作，而不是原始流。

findFirst()中使用的forEachWithCancel()的实现，不断地在spliterator上调用tryAdvance()，直到sink请求取消或者 spliterator 已耗尽。在 flatMap() 的情况下，即使 filter() 已经找到匹配项，分裂器也会继续前进，而不会提前终止。

修复

这个问题已在 Java 10 中得到解决，并向后移植到 Java 8。现在，当像 filter() 这样的短路操作被执行时，该实现允许在 flatMap() 中提前终止。

结论

可以理解的是，为什么filter()在flatMap()之后表现得好像不是懒惰的，这可能会令人困惑。底层 Java Streams 实现规定了这种行为，后来在 Java 10 中解决了这一问题，并向后移植到 Java 8。这种理解对于有效处理此类场景至关重要。

以上是为什么 Java Streams 中的'filter()”在'flatMap()”之后显得不那么懒惰？的详细内容。更多信息请关注PHP中文网其他相关文章！