API文档没有这样的保证“后续 *** 作将不再对后备集合进行 *** 作”,因此,您永远不应依赖于特定实现的这种行为。
您的示例碰巧偶然地完成了所需的 *** 作;甚至不能保证
List创建的by
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()可以转换为“查找最小值” *** 作,而无需将元素复制到新存储中进行排序。
因此,最重要的是,当依赖于未指定的行为时,今天发生的事情可能会在明天添加新的优化措施而中断。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)