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，即使它实现了您的直接目标。这种方法将来可能会中断，未来的维护者也不清楚。

将此分解为多个操作没有任何害处，因为它们是不同的操作。以不明确和无意的方式使用API会造成损害，如果在将来的Java版本中修改此特定行为，则可能会产生影响。

在此操作上使用forEach将使维护者明白，accounts的每个元素都存在预期的副作用，并且您正在执行某些操作可以改变它。

在某种意义上，peek是一个中间操作，在终端操作运行之前不会对整个集合进行操作，但是forEach确实是终端操作。这样，您可以围绕行为和代码流进行强有力的论证，而不是询问peek在此上下文中forEach的行为是否与accounts.forEach(a -> a.login()); List<Account> loggedInAccounts = accounts.stream() .filter(Account::loggedIn) .collect(Collectors.toList());相同。

var db = new pouchdb('meetups');
db.allDocs({
    include_docs: true,
    attachments: true
}).then(function (err,res) {
    console.log("Result..."+res);
    res.json({'users':res});
}).catch(function (err) {
    console.log(err);
});

Answer 3

也许一个经验法则应该是，如果你在＆＃34; debug＆＃34;之外使用peek。在这种情况下，如果您确定终止和中间过滤条件是什么，则应该这样做。例如：

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实际上似乎是最干净的方式。

与您的用例类似，假设您只想过滤活动帐户，然后对这些帐户执行登录。

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());

Answer 6

我想说peek可以去中心化可以使流对象变异或修改全局状态（基于它们）的代码，而不是将所有内容填充到简单或组合函数传递给终端方法。

现在的问题可能是：我们应该在函数式Java编程的函数中对流对象进行突变还是更改全局状态？？

如果以上两个问题中的任何一个答案为是（或：在某些情况下为是），那么peek()肯定是不仅用于调试目的，对于同样的原因，forEach()不仅用于调试目的。

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

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

PS 我没有在任何地方引用过map()，因为如果我们想改变对象（或全局状态）而不是生成新对象，它的工作原理就和peek()一样

Answer 7

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

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

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

话虽如此，我同意使用 .peek 时的所有考虑，例如意识到使用它的流的终端操作的影响。

Answer 8

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

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

8 个答案: