Java流懒惰与融合和短路

我正在尝试在Java流API中形成一个关于懒惰评估应用的cocise和一致的理解。

这是我目前理解的：

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

我想要做的就是将所有这些想法结合起来，确保我不会歪曲任何事情。 我发现它很棘手，因为每当我阅读任何有关Java流的文献时，它都会说它们是懒惰的或利用懒惰的评估，然后非常可互换地开始讨论优化，如融合和短路。

所以我说对于以下内容是对的吗？

  • 融合是如何在流API中实现延迟评估 – 即消耗元素，并且尽可能将操作融合在一起。 我认为如果不存在融合那么我们肯定会回到急切的评估，因为替代方案只是处理每个中间操作的所有元素，然后再转移到下一个中​​间操作？

  • 如果没有融合或懒惰的评估，短路是可能的，但通过这两个原则的实施，在流的背景下是非常有帮助的吗？

我对此有任何进一步的见解和清晰度表示感谢。

至于融合。 让我们想象一下这是一个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 ，直接连接到源。 处理每个元素时，源分裂器只执行组合的使用者，流管道不拦截任何内容并且不执行任何额外的簿记。 这是融合。 Fusion不依赖于短路。 可以在没有融合的情况下实现流（执行一个操作，获取结果，执行下一个操作，在每个操作之后将控制权返回到流引擎）。 也可以在没有短路的情况下进行融合。

Interesting Posts