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

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

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

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

很多答案都有很好的观点，尤其是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 by list::add例如，在一些回答中也做过)，并返回添加了多少数据。目前观察到的情况是，任何可以过滤元素的操作(如过滤或跳过)似乎都强制处理所有剩余的元素，但不需要保持这种方式。

关键是:

不要以一种意想不到的方式使用API，即使它实现了您的直接目标。这种方法在将来可能会失效，而且对于未来的维护者来说也不清楚。

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

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

它也更传统，因为peek是一个中间操作，在终端操作运行之前不会对整个集合进行操作，但forEach确实是一个终端操作。通过这种方式，您可以围绕代码的行为和流程进行强有力的论证，而不是询问peek在此上下文中的行为是否与forEach相同。

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

似乎需要一个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;
        };
    }
}

然后切换偷看与地图:

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

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

您必须了解的重要一点是，流是由终端操作驱动的。终端操作决定是否必须处理所有元素，或者是否必须处理任何元素。因此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文档所说的:

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

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

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

你可以替换:

  .peek(f)

with

  .map(tee(f))