我正在阅读有关Java流的资料，并在阅读过程中发现新的东西。我发现的一个新东西是peek()函数。几乎所有我读到的peek说它应该用来调试你的流。
如果我有一个流，其中每个帐户都有一个用户名，密码字段和login()和loggedIn()方法。
我还有
Consumer<Account> login = account -> account.login();
and
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();
})
尽管.peek的文档说明说“方法的存在主要是为了支持调试”，但我认为它具有普遍的相关性。首先，文档说“主要”，所以为其他用例留下了空间。多年来它没有被弃用，在我看来，关于它被移除的猜测是徒劳的。
我想说，在一个我们仍然需要处理副作用方法的世界里，它有一个有效的位置和效用。流中有许多使用副作用的有效操作。许多已经在其他答案中提到，我只是在这里添加一个对象集合上设置一个标志，或者将它们注册到注册表中，然后在流中进一步处理对象。更不用说在流处理期间创建日志消息了。
我支持在不同的流操作中有不同的动作的想法，因此我避免将所有内容都推入最终的. foreach。我更喜欢.peek而不是等效的带有lambda的.map，除了调用副作用方法之外，它的唯一目的是返回传入的in参数。.peek告诉我，一旦遇到这个操作，输入的内容也会输出，而且我不需要读取lambda来找出。从这个意义上说，它是简洁的，富有表现力的，并提高了代码的可读性。
话虽如此，我同意使用.peek时的所有注意事项，例如，注意使用.peek的流的终端操作的影响。
我想说的是，peek提供了去中心化代码的能力，这些代码可以改变流对象，或修改全局状态(基于它们)，而不是将所有东西都塞进一个简单的或组合的函数中，传递给终端方法。
现在的问题可能是:在函数式java编程中，我们应该改变流对象还是从函数内部改变全局状态?
如果以上两个问题中的任何一个的答案是肯定的(或者:在某些情况下是)，那么peek()肯定不仅仅是用于调试的目的，就像forEach()不仅仅是用于调试的目的一样。
对于我来说，当在forEach()和peek()之间进行选择时，是选择以下内容:我想要突变流对象(或改变全局状态)的代码片段附加到可组合的，还是我想要它们直接附加到流?
我认为peek()将更好地与java9方法配对。例如，takeWhile()可能需要根据一个已经发生变化的对象决定何时停止迭代，因此与forEach()匹配将不会产生相同的效果。
注:我没有在任何地方提到map()，因为如果我们想要突变对象(或全局状态)，而不是生成新对象，它的工作方式与peek()完全相同。
尽管.peek的文档说明说“方法的存在主要是为了支持调试”，但我认为它具有普遍的相关性。首先，文档说“主要”，所以为其他用例留下了空间。多年来它没有被弃用，在我看来，关于它被移除的猜测是徒劳的。
我想说，在一个我们仍然需要处理副作用方法的世界里，它有一个有效的位置和效用。流中有许多使用副作用的有效操作。许多已经在其他答案中提到，我只是在这里添加一个对象集合上设置一个标志，或者将它们注册到注册表中，然后在流中进一步处理对象。更不用说在流处理期间创建日志消息了。
我支持在不同的流操作中有不同的动作的想法，因此我避免将所有内容都推入最终的. foreach。我更喜欢.peek而不是等效的带有lambda的.map，除了调用副作用方法之外，它的唯一目的是返回传入的in参数。.peek告诉我，一旦遇到这个操作，输入的内容也会输出，而且我不需要读取lambda来找出。从这个意义上说，它是简洁的，富有表现力的，并提高了代码的可读性。
话虽如此，我同意使用.peek时的所有注意事项，例如，注意使用.peek的流的终端操作的影响。
您必须了解的重要一点是，流是由终端操作驱动的。终端操作决定是否必须处理所有元素，或者是否必须处理任何元素。因此collect是处理每个项的操作，而findAny在遇到匹配元素时可能会停止处理项。
And count() may not process any elements at all when it can determine the size of the stream without processing the items. Since this is an optimization not made in Java 8, but which will be in Java 9, there might be surprises when you switch to Java 9 and have code relying on count() processing all items. This is also connected to other implementation-dependent details, e.g. even in Java 9, the reference implementation will not be able to predict the size of an infinite stream source combined with limit while there is no fundamental limitation preventing such prediction.
Since peek allows “performing the provided action on each element as elements are consumed from the resulting stream”, it does not mandate processing of elements but will perform the action depending on what the terminal operation needs. This implies that you have to use it with great care if you need a particular processing, e.g. want to apply an action on all elements. It works if the terminal operation is guaranteed to process all items, but even then, you must be sure that not the next developer changes the terminal operation (or you forget that subtle aspect).
此外，虽然流保证维持某些操作组合的遇到顺序，即使是并行流，但这些保证并不适用于peek。当收集到列表中时，结果列表将具有有序并行流的正确顺序，但peek操作可能以任意顺序并发调用。
因此，你可以用peek做的最有用的事情是找出一个流元素是否被处理了，这正是API文档所说的:
此方法的存在主要是为了支持调试，在调试中，您希望看到元素流经管道中的某个点时的情况
