这周遇到了一件很有意思的事情。在看项目代码时,发现了这么一段:
return objects.stream()
.peek(object -> addInfo(object, someParams))
.collect(Collectors.toList());
因为之前没接触过 peek()
,这段代码看得我云里雾里。
后来在 这个链接 里读到这样一句话:
On top of that, peek() can be useful in another scenario: when we want to alter the inner state of an element.
翻译过来就是:
除此之外,peek() 还有另一种用途:改变元素的内部状态
这样一来,就不难理解上面代码的意图了:对每个 object
执行 addInfo(object, someParams)
,然后把结果收集到一个 List
里。
但后来又看了一些讨论,发现这个用法在这里虽然不算错,但并不是 peek()
最合理的用法。
为什么呢?因为 peek()
并不是一个最终操作(terminal operation)。出于性能考虑,stream 被设计为“元素只有在最终操作需要时才会被处理”。如果没有最终操作的“拉动”,那么 stream 中就没有操作会真正执行。
在上面的例子中,.collect(Collectors.toList())
就是一个最终操作,而且这个操作会“拉动”所有元素。这样一来,每个元素都一定会被应用 peek()
方法,所以放在这里没有问题。
但在使用 peek()
时仍然需要注意,因为它只保证作用于流经管道的元素,但并不保证全部元素都会流经管道。
forEach()
则是一个最终操作。除此之外,peek()
和 forEach()
再无其他不同。
顾名思义,forEach()
就是保证对 stream 里的每个元素都应用某个方法。如果这是你的意图,那么最好用 forEach()
而不是 peek()
,这样代码会便于理解。如果上面的代码用的是 forEach()
,那我一开始也不至于看不懂了。
正因为 peek()
不是一个最终操作,不会影响“哪些元素会流过”,所以十分适合在调试的时候,用来打印出流经管道的元素。例如:
Stream.of("one", "two", "three", "four")
.filter(e -> e.length() > 3)
.peek(e -> System.out.println("Filtered value: " + e))
.map(String::toUpperCase)
.peek(e -> System.out.println("Mapped value: " + e))
.collect(Collectors.toList());
forEach()
;peek()
;In Java streams is peek really only for debugging?
Non-terminal forEach() in a stream?