在Java流是peek真的只是调试?

小开

你必须了解的重要事情是，流是由终端操作驱动的。终端操作决定是否必须处理所有元素，或者是否必须处理任何元素。因此，collect是处理每个项的操作，而findAny在遇到匹配元素时可能会停止处理项。

当count()可以确定流的大小而不处理项时，它可能根本不处理任何元素。由于这不是在Java 8中进行的优化，但将在Java 9中进行，当你切换到Java 9并有依赖count()处理所有项的代码时，可能会感到惊讶。这也连接到其他依赖于实现的细节，例如，即使在Java 9中，参考实现也不能预测与limit结合的无限流源的大小，而没有基本限制阻止这种预测。

由于peek允许“对每个元素作为从结果流中消费的元素执行所提供的操作”，因此它不强制处理元素，而是根据终端操作的需要执行操作。这意味着如果你需要一个特定的处理，例如想要对所有元素应用一个操作，你必须非常小心地使用它。如果保证终端操作处理所有项，那么它就可以工作，但即使这样，您也必须确保下一个开发人员不会更改终端操作(否则您会忘记这个微妙的方面)。

此外，虽然流保证维护某些操作组合的遇到顺序，即使是并行流，但这些保证不适用于peek。当收集到列表中时，结果列表将具有有序并行流的正确顺序，但peek操作可能以任意顺序并发调用。

因此，你可以用peek做的最有用的事情是找出一个流元素是否已经被处理，这正是API文档所说的:

此方法的存在主要是为了支持调试，在调试中，您希望看到元素流经管道中的某个点时的情况

小开

最佳答案

关键是:

这种方法在未来可能会中断，而且对于未来的维护者来说也不清楚。

将其分解为多个操作并没有害处，因为它们是不同的操作。以一种不明确和意外的方式使用API有是危害，如果在未来的Java版本中修改这种特定的行为，可能会产生后果。

在此操作中使用forEach将使维护者清楚地知道，在accounts的每个元素上都有目的副作用，并且您正在执行一些可能会改变它的操作。

在某种意义上，peek是一个中间操作，在终端操作运行之前不会对整个集合进行操作，但forEach确实是一个终端操作。这样，您就可以围绕代码的行为和流程进行强有力的论证，而不是询问在此上下文中peek的行为是否与forEach的行为相同。

accounts.forEach(a -> a.login());
List<Account> loggedInAccounts = accounts.stream()
.filter(Account::loggedIn)
.collect(Collectors.toList());

小开

也许经验法则应该是，如果您确实在“调试”场景之外使用peek，那么只有在确定终止和中间过滤条件是什么时才应该这样做。例如:

return list.stream().map(foo->foo.getBar())
.peek(bar->bar.publish("HELLO"))
.collect(Collectors.toList());

似乎是一个有效的情况，在一个操作中，将所有的foo转换为bar，并告诉他们都是你好。

似乎比下面的东西更高效和优雅:

List<Bar> bars = list.stream().map(foo->foo.getBar()).collect(Collectors.toList());
bars.forEach(bar->bar.publish("HELLO"));
return bars;

而且你最终不会迭代一个集合两次。

小开

虽然我同意上面的大多数答案，但我有一个案例，使用peek似乎是最干净的方法。

与您的用例类似，假设您希望仅对活动帐户进行过滤，然后在这些帐户上执行登录。

accounts.stream()
.filter(Account::isActive)
.peek(login)
.collect(Collectors.toList());

Peek有助于避免冗余调用，同时不必迭代集合两次:

accounts.stream()
.filter(Account::isActive)
.map(account -> {
account.login();
return account;
})
.collect(Collectors.toList());

小开

我会说peek提供了分散可以改变流对象或修改全局状态的代码的能力(基于它们)，而不是把所有东西都塞进传递给终端方法的简单或组合函数中。

现在的问题可能是:在函数式Java编程中，我们应该改变流对象还是从函数内部改变全局状态?

如果以上两个问题的答案是肯定的(或者:在某些情况下是)，那么peek()是当然不仅仅是为了调试目的， 出于同样的原因，forEach()不仅仅是为了调试目的。

对我来说，当在forEach()和peek()之间进行选择时，是选择以下内容:我想要将改变流对象(或改变全局状态)的代码片段附加到可组合对象上，还是希望它们直接附加到流上?

我认为peek()将更好地与java9方法配对。例如，takeWhile()可能需要根据已经发生变化的对象决定何时停止迭代，因此将其与forEach()相提并论不会产生相同的效果。

注:我没有在任何地方提到map()，因为如果我们想要突变对象(或全局状态)，而不是生成新对象，它的工作方式与peek()完全相同。

小开

功能性的解决方案是使帐户对象不可变。因此account.login()必须返回一个新的account对象。这意味着映射操作可以用于登录，而不是查看。

小开

很多答案都有很好的观点，尤其是Makoto(被接受的)的答案相当详细地描述了可能存在的问题。但没有人真正说明它是如何出错的:

[1]-> IntStream.range(1, 10).peek(System.out::println).count();
|  $6 ==> 9

没有输出。

[2]-> IntStream.range(1, 10).filter(i -> i%2==0).peek(System.out::println).count();
|  $9 ==> 4

输出数字2,4,6,8。

[3]-> IntStream.range(1, 10).filter(i -> i > 0).peek(System.out::println).count();
|  $12 ==> 9

输出数字1 ~ 9。

[4]-> IntStream.range(1, 10).map(i -> i * 2).peek(System.out::println).count();
|  $16 ==> 9

没有输出。

[5]-> Stream.of(1, 2, 3, 4, 5, 6, 7, 8, 9).peek(System.out::println).count();
|  $23 ==> 9

没有输出。

[6]-> Arrays.asList(1, 2, 3, 4, 5, 6, 7, 8, 9).stream().peek(System.out::println).count();
|  $25 ==> 9

没有输出。

[7]-> IntStream.range(1, 10).filter(i -> true).peek(System.out::println).count();
|  $30 ==> 9

输出数字1 ~ 9。

[1]-> List<Integer> list = new ArrayList<>();
|  list ==> []
[2]-> Stream.of(1, 5, 2, 7, 3, 9, 8, 4, 6).sorted().peek(list::add).count();
|  $7 ==> 9
[3]-> list
|  list ==> []

(你懂的。)

这些例子是在jshell (Java 15.0.2)中运行的，并模拟了转换数据的用例(例如，将System.out::println替换为list::add，这在一些答案中也做过)并返回添加了多少数据。目前观察到的情况是，任何可以过滤元素的操作(如过滤或跳过)似乎都强制处理所有剩余的元素，但不需要保持这种方式。

小开

尽管.peek的文档说明说方法的存在主要是为了支持调试。，但我认为它具有普遍的相关性。首先，文档说“主要”，所以为其他用例留下了空间。多年来它没有被弃用，在我看来，关于它被移除的猜测是徒劳的。

我想说，在一个我们仍然需要处理副作用方法的世界里，它有一个有效的位置和效用。流中有许多使用副作用的有效操作。许多已经在其他答案中提到，我只是在这里添加一个对象集合上设置一个标志，或者将它们注册到注册表中，然后在流中进一步处理对象。更不用说在流处理期间创建日志消息了。

我支持在不同的流操作中有不同的动作的想法，因此我避免将所有内容都推入最终.forEach。我更喜欢.peek而不是等价的带有lambda的.map，它的唯一目的，除了调用副作用方法之外，就是返回传入的参数。.peek告诉我，当我遇到这个操作时，输入的内容也会输出，并且我不需要读取lambda来查找。从这个意义上说，它是简洁的，富有表现力的，并提高了代码的可读性。

话虽如此，我同意使用.peek时的所有注意事项，例如，注意使用它的流的终端操作的影响。

小开

似乎需要一个helper类:

public static class OneBranchOnly<T> {
public Function<T, T> apply(Predicate<? super T> test,
Consumer<? super T> t) {
return o -> {
if (test.test(o)) t.accept(o);
return o;
};
}
}

然后将peek转换为map:

.map(new OneBranchOnly< Account >().apply(
account -> account.isTestAccount(),
account -> account.setName("Test Account"))
)

结果:只重命名测试帐户的帐户集合(没有维护引用)

小开

为了消除警告，我使用函数tee，以Unix的三通命名:

public static <T> Function<T,T> tee(Consumer<T> after) {
return arg -> {
f.accept(arg);
return arg;
};
}

你可以替换:

  .peek(f)

与

  .map(tee(f))