在Java流中,窥视真的只用于调试吗？

Question

我正在阅读有关Java流和发现新事物的内容.我发现的新事物之一是peek()功能.几乎所有我读过的内容都说它应该用来调试你的Streams.

如果我有一个Stream,每个帐户都有一个用户名,密码字段以及login()和loggedIn()方法,该怎么办？

我也有

Consumer<Account> login = account -> account.login();

和

Predicate<Account> loggedIn = account -> account.loggedIn();

为什么会这么糟糕？

List<Account> accounts; //assume it's been setup
List<Account> loggedInAccount = 
accounts.stream()
    .peek(login)
    .filter(loggedIn)
    .collect(Collectors.toList());

现在据我所知,这完全符合它的目的.它;

• 获取帐户列表
• 尝试登录每个帐户
• 过滤掉任何未登录的帐户
• 将登录的帐户收集到新列表中

做这样的事情的缺点是什么？有什么理由我不应该继续吗？最后,如果不是这个解决方案呢？

其原始版本使用.filter()方法如下;

.filter(account -> {
        account.login();
        return account.loggedIn();
    })

Answer 1

您必须要了解的重要一点是,流是由终端操作驱动的.终端操作确定是否必须处理所有元素或者根本不处理所有元素.collect处理每个项目的操作也是如此,而findAny一旦遇到匹配元素就可以停止处理项目.

并且count()当它可以在不处理项目的情况下确定流的大小时,可能根本不处理任何元素.由于这是一个不是在Java 8中进行的优化,而是在Java 9中进行的优化,因此当您切换到Java 9并且依赖于count()处理所有项目的代码时可能会出现意外情况.这也与其他依赖于实现的细节相关联,例如,即使在Java 9中,参考实现也将不能预测无限流源的大小,limit同时没有阻止这种预测的基本限制.

由于peek允许"在从结果流中消耗元素时对每个元素执行所提供的操作",因此它不会强制要求处理元素,而是根据终端操作需要执行操作.这意味着如果您需要特定的处理,您必须非常谨慎地使用它,例如想要对所有元素应用操作.如果终端操作保证处理所有项目,它就有效,但即便如此,您必须确保下一个开发人员不会更改终端操作(或者您忘记了那个微妙的方面).

此外,虽然流保证即使对于并行流也保持某些操作组合的遭遇顺序,但这些保证不适用于peek.收集到列表中时,结果列表将具有有序并行流的正确顺序,但peek可以以任意顺序同时调用该操作.

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

此方法主要用于支持调试,您希望在元素流经管道中的某个点时查看这些元素

Answer 2

关键是要点:

不要以非预期的方式使用API​​,即使它实现了您的直接目标.这种方法将来可能会破裂,未来的维护者也不清楚.

将此分解为多个操作没有任何害处,因为它们是不同的操作.还有就是在不明确的和意想不到的方式,如果这种特定的行为是用Java的未来版本中修改其可能的后果使用API的伤害.

使用forEach此操作将使维护者清楚地知道每个元素都存在预期的副作用accounts,并且您正在执行一些可以改变它的操作.

在某种意义上它也是更常规的,即peek在终端操作运行之前不对整个集合进行操作的中间操作,但forEach实际上是终端操作.这样,您可以围绕代码的行为和流程进行强有力的论证,而不是询问有关if peek是否与forEach此上下文中的行为相同的问题.

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

Answer 3

也许一个经验法则应该是,如果你在"调试"场景之外使用窥视,你应该只在你确定终止和中间过滤条件是什么时才这样做.例如:

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

似乎是一个有效的案例,你想要在一个操作中将所有Foos转换为Bars并告诉他们所有你好.

似乎比以下更有效和优雅:

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

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

Answer 4

很多答案都提出了很好的观点，特别是 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，如某些答案中所做的那样）并返回添加了多少数据。目前的观察是，任何可以过滤元素的操作（例如过滤或跳过）似乎都会强制处理所有剩余元素，但它不需要保持这种状态。

Answer 5

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

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

如果回答任何的上述2个问题是肯定的（或：在某些情况下是），则peek()是绝对不仅是为了调试的目的，对于同样的原因，forEach()不仅是为了调试的目的。

对我来说，在forEach()和之间peek()进行选择时，是选择以下内容：我是否希望将改变流对象的代码片段附加到可组合对象，还是希望它们直接附加到流？

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

PS我没有map()在任何地方引用，因为如果我们想要改变对象（或全局状态），而不是生成新对象，它的工作方式与peek().

Answer 6

尽管文档注释.peek说“该方法的存在主要是为了支持调试”，但我认为它具有普遍的相关性。一方面，文档说“主要”，因此为其他用例留出了空间。它多年来一直没有被弃用，并且关于它被删除的猜测在我看来是徒劳的。

我想说，在我们仍然必须处理副作用方法的世界中，它具有有效的地位和实用性。流中有许多使用副作用的有效操作。其他答案中已经提到了许多内容，我将在此处添加以在对象集合上设置标志，或在对象上将它们注册到注册表，然后在流中进一步处理这些对象。更不用说在流处理期间创建日志消息了。

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

话虽如此，我同意使用时的所有考虑因素.peek，例如了解其所使用的流的终端操作的影响。

Answer 7

尽管我同意上面的大多数答案，但我有一个案例，其中使用 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());