微信公众号搜"智元新知"关注
微信扫一扫可直接关注哦!

java – Peek()真正看到元素流过管道中的某个点

我的问题以最简单的方式表达:

根据JavaDoc

Peek() method exists mainly to support debugging,where you want to
see the elements as they flow past a certain point in a pipeline.

我有一个10米的管道,距离3到7米
从输入头我有两个标记[aka peek()]用于检查/调试我的元素.

现在从输入端我输入1,2,3,4,5.

在x = 4米处,我有一个过滤器(),它过滤所有小于等于3的元素.

现在按照Java doc我应该能够看到我在3米和7米距离的管道输入发生了什么.

marker1距离3(.peek())的输出应该是1,5不应该是??
标记2在距离7处的输出应该明显为4.5.

但这实际上并没有发生,产量在第一市场(.peek())仅为1,第二市场为4,5.

我为测试我的理论而执行的代码

final List<Integer> IntList=
    Stream.of(1,5)
    .peek(it -> System.out.println("Before Filtering "+it)) // should print 1,5
    .filter(it -> it >= 3)
    .peek(it -> System.out.println("After Filtering: "+it)) //should print 4,5
    .collect(Collectors.toList());

实际产量:

Before Filtering 1
Before Filtering 2
Before Filtering 3
After Filtering: 3
Before Filtering 4
After Filtering: 4
Before Filtering 5
After Filtering: 5

预期输出(阅读JavaDoc之后开发人员应该想到什么(…主要用于支持调试,在这里你想要看到元素流过管道中的某个点…)

Before Filtering 1
    Before Filtering 2
    Before Filtering 3
    Before Filtering 4
    Before Filtering 5
    After Filtering: 4
    After Filtering: 5

如果.peek()不只是在管道中的特定点进行调试,那么def就不明确了.

对不起我的管道故事,我想这样我可以解释我最想问的问题.

解决方法

不需要.可以根据需要懒惰地评估流,并且操作顺序没有明确定义,尤其是当你偷看()时.这允许流API支持非常大的流而不会浪费大量时间和内存,并且允许某些实现简化.特别是,在下一阶段之前,不需要对管道的单个阶段进行全面评估.

假设您的假设如下,假设以下代码有多浪费:

IntStream.range(1,1000000).skip(5).limit(10).forEach(System::println);

流以一百万个元素开始,最后为10.如果我们完全评估每个阶段,我们的中间体将分别为100万,999995和10个元素.

作为第二个示例,以下流不能一次评估一个阶段(因为IntStream.generate返回无限流):

IntStream.generate(/* some supplier */).limit(10).collect(Collectors.toList());

您的管道确实通过第一个窥视传递每个元素,然后通过第二个窥视只传递一个子集.但是,管道以元素主要而不是阶段主要顺序执行此评估:它将管道评估为1,将其放在过滤器处,然后2.一旦评估管道为3,它就会通过过滤器,因此两者都是偷看语句执行,然后发生4和5.

版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。

相关推荐