我的问题以最简单的方式表达:
根据 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 meter 处,我有一个 filter()
过滤所有小于 小于和等于 的元素3
。
现在,根据 Java 文档,我应该能够在距离 3
和 7
米处看到我在管道中的输入发生了什么。
在 marker1 处 distance 3 的输出(.peek()
)应该是 1,2,3,4,5
不应该是??
并且 marker2 处 distance 7 的输出显然应该是 4,5
。
但这实际上并没有发生,输出来自第一个市场(.peek())只是 1,2,3
而第二个是 4,5
.
我为测试我的理论而执行的代码:
final List<Integer> IntList=
Stream.of(1, 2, 3, 4, 5)
.peek(it -> System.out.println("Before Filtering "+it)) // should print 1,2,3,4,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 是不明确的。
抱歉我的 Pipe 故事,我想这样我可以最好地解释我想问的问题。
最佳答案
Andrey Akhmetov 的回答是正确的,但我想补充一下,因为这里有两个问题。一个是流管道语义的一般问题——这正是您的问题所在。第二个是关于 peek()
的含义和限制。
对于主要问题——这与 peek()
无关,除了你是如何观察正在发生的事情的状态——你对流的直觉是完全错误的。没有理由相信:
collection.stream()
.filter(x -> x.foo() > 3)
.map(X::toBar)
.forEach(b -> System.out.println("Bar: " + b);
所有过滤发生在所有打印之前的所有映射之前。流可以按照它喜欢的任何顺序自由交织过滤、映射和打印。 (在聚合中有一些排序保证。)这里的好处是,在某些具有无限流的情况下,这通常具有更高的性能、更可并行化和更健壮。只要您遵守规则(即,不要依赖一个阶段对另一个阶段的副作用),您就无法分辨出区别,除非您的代码运行得更快。
peek()
语言的 Swing 不定的原因在于:
int size = collection.stream()
.map(...)
.peek(...)
.count()
我们可以在不进行任何映射的情况下评估答案(因为众所周知 map() 是一种大小保持操作。)始终在 peek()< 处提供元素的要求
点会破坏许多有用的优化。因此,如果可以证明它不会影响答案,则该实现可以自由地省略管道的整个中间部分。 (它可能会产生更少的副作用,但如果您如此关心副作用,也许您不应该使用流。)
关于java - Peek() 真正地看到元素流过管道中的某个点,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/54405863/