Stream.peek更改状态的可能副作用，为什么不像这样使用它

Question

我想到的另一个Stackoverflow问题的解决方案是使用Stream.peek操作，但似乎仍然不正确，因为它会改变< code>Stream.peek方法中的状态。

同时在＜code＞流上研究（这里和这里）。查看用法是否可以改变状态我仍然不完全相信＜code＞流。peek不应改变状态（包括＜code＞流

下面是Javadoc所说的：

此方法主要用于支持调试，您希望在元素流经管道中的某个点时看到它们：

然后：

参数：action-在元素从流中消耗时对其执行的非干扰操作。

对于性能良好的无干扰流源，可以在终端操作开始之前修改源，并且这些修改将反映在所覆盖的元素中。从JDK集合返回的所有流，以及大多数其他JDK类，都以这种方式表现良好。

似乎无干扰操作确实包括改变流中集合的状态。

下面是使用< code>Stream.peek的代码。

Map< String, List<Test> > userTests = new HashMap<>();

Map< String, List<Test> > filtered  = userTests.entrySet().stream()
        .peek( e -> e.setValue( modifyListAndReturnIt( e.getValue() ) ) )
        .filter( e -> !e.getValue().isEmpty() ) //check if modified list in peek has been emptied
        .collect( Collectors.toMap(p -> p.getKey(), p -> p.getValue() ) );

    public static List<Test> modifyListAndReturnIt(List<Test> list){
        if (somecondition) list.clear();
        return list;
    }

1）上面的代码会有什么副作用吗？

2)为什么不这样使用peek。Javadoc似乎不允许这样做。

Answer 1

你似乎做了什么看起来无害，正如Brian Goetz在这里的评论中所说的那样。

现在peek的问题是，如果你在它里面产生副作用，你会期望这些副作用真的发生。所以，假设你想像这样改变某个对象的属性:

myUserList.stream()
          .peek(u -> u.upperCaseName())
          .count()

在java-8中，你的peek确实会被调用，在9中 - 它不是 - 没有必要在这里调用peek，因为无论如何都可以在没有它的情况下计算大小。

在同一条路径上，假设您的终端操作是短路操作，如＜code＞findFirst-您不会处理源代码的所有元素-您可能只通过管道获得其中的一些元素。

如果你的＜code＞窥视