每个有状态的中间 Stream API 操作是否都能保证新的源集合？

以下陈述是否正确？

The sorted()操作是“有状态中间操作”，这意味着后续操作不再对后备集合进行操作，而是对内部状态进行操作。

^{(Source https://www.toptal.com/java/top-10-most-common-java-development-mistakes and source https://dzone.com/articles/java-8-friday-10-subtle - they seem to copy from each other or come from the same source.)}

免责声明：我知道以下代码片段不是 Java Stream API 的合法用法。不要在生产代码中使用。

我测试过Stream::sorted https://docs.oracle.com/javase/8/docs/api/java/util/stream/Stream.html#sorted--作为上述来源的片段：

final List<Integer> list = IntStream.range(0, 10).boxed().collect(Collectors.toList());
    
list.stream()
    .filter(i -> i > 5)
    .sorted()
    .forEach(list::remove);

System.out.println(list);            // Prints [0, 1, 2, 3, 4, 5]

有用。我更换了Stream::sorted https://docs.oracle.com/javase/8/docs/api/java/util/stream/Stream.html#sorted-- with Stream::distinct https://docs.oracle.com/javase/8/docs/api/java/util/stream/Stream.html#distinct--, Stream::limit https://docs.oracle.com/javase/8/docs/api/java/util/stream/Stream.html#limit-long- and Stream::skip https://docs.oracle.com/javase/8/docs/api/java/util/stream/Stream.html#skip-long-:

final List<Integer> list = IntStream.range(0, 10).boxed().collect(Collectors.toList());
    
list.stream()
    .filter(i -> i > 5)
    .distinct()
    .forEach(list::remove);          // Throws NullPointerException

令我惊讶的是，NullPointerException被抛出。

所有测试方法均遵循有状态中间操作 https://docs.oracle.com/javase/8/docs/api/java/util/stream/package-summary.html#StreamOps特征。然而，这种独特的行为Stream::sorted https://docs.oracle.com/javase/8/docs/api/java/util/stream/Stream.html#sorted--没有记录也没有流操作和管道 https://docs.oracle.com/javase/8/docs/api/java/util/stream/package-summary.html#StreamOps部分解释了是否有状态中间操作真正保证新源合集。

我的困惑从何而来？上述行为的解释是什么？

API 文档没有做出这样的保证“后续操作不再对后备集合进行操作”，因此，您永远不应该依赖特定实现的这种行为。

你的例子碰巧做了你想要的事情;甚至不能保证List由...制作collect(Collectors.toList())支持remove手术。

展示一个反例

Set<Integer> set = IntStream.range(0, 10).boxed()
    .collect(Collectors.toCollection(TreeSet::new));
set.stream()
    .filter(i -> i > 5)
    .sorted()
    .forEach(set::remove);

抛出一个ConcurrentModificationException。原因是该实现优化了这种情况，因为源已经排序。原则上，它可以对原始示例进行相同的优化，如下所示forEach未按指定顺序显式执行操作，因此不需要排序。

还有其他可以想象的优化，例如sorted().findFirst()可以转换为“查找最小值”操作，而不需要将元素复制到新的存储中进行排序。

所以底线是，当依赖于未指定的行为时，今天可能发生的事情可能会在明天添加新的优化时失效。