Java 流惰性 vs 融合 vs 短路

Question

我正在尝试对惰性求值在 Java 流 API 中的应用形成一个简洁而连贯的理解。

这是我目前的理解:

• 元素仅在需要时才被消耗，即流是惰性的，中间操作也是惰性的，例如过滤器，仅在需要时进行过滤。
• 中间操作可以融合在一起(如果它们是无状态的)。
• 短路操作不需要处理整个流。

我想做的是将所有这些想法结合起来，确保我没有歪曲任何内容。我发现它很棘手，因为每当我阅读有关 Java 流的任何文献时，它都会继续说它们是惰性的或利用惰性评估，然后非常互换地开始谈论融合和短路等优化。

那么我下面的说法对吗？

• 融合是在流 API 中实现惰性评估的方式 - 即消耗一个元素，并尽可能将操作融合在一起。我在想，如果融合不存在，那么我们肯定会回到急切的评估，因为替代方案只是在进入下一个之前处理每个中间操作的所有元素？

• 在没有融合或懒惰求值的情况下短路是可能的，但在流的上下文中通过这两个原则的实现有很大帮助？

如果对此有任何进一步的见解和澄清，我将不胜感激。

Answer 1

至于融合。假设这是一个 map 操作:

.map(x -> x.squash())

它是无状态的，它只是根据指定的算法转换任何输入(在我们的例子中压缩它们)。现在过滤操作:

.filter(x -> x.getColor() != YELLOW)

它也是无状态的，它只是删除了一些元素(在我们的例子中是黄色的)。现在让我们进行终端操作:

.forEach(System.out::println)

它只是将输入元素显示到终端。融合意味着所有中间无状态操作都与终端消费者合并为单个操作:

.map(x -> x.squash())
.filter(x -> x.getColor() != YELLOW)
.forEach(System.out::println)

整个管道被融合成一个直接连接到源的Consumer。当处理完每一个元素时，源拆分器只执行组合的消费者，流管道不拦截任何东西，也不执行任何额外的簿记。那就是融合。融合不依赖于短路。可以在不融合的情况下实现流(执行一个操作，获取结果，执行下一个操作，在每个操作后将控制权交还给流引擎)。也可以在不短路的情况下进行融合。