Stream.forEach是否遵守顺序流的遇到顺序？
Javadoc
Stream.forEach表示（重点是我）：
该操作的行为明确地是不确定的。
，因为这样做会牺牲并行性的好处。对于任何给定的元素，可以在库选择的任何时间和线程中执行操作。如果操作访问共享状态，则它负责提供所需的同步。
Java 9 Early Access
Javadoc中提供了相同的文本。
第一句话（“明确地不确定”）表明（但未明确说明）此方法未保留遇到顺序。但是下一个句子（明确表示未保留顺序）以“用于并行流管道”为条件，并且如果应用该句子而不考虑并行性，则该条件将是不必要的。这使我不确定forEach是否保留顺序流的遇到顺序。
这个答案 指出了流库实现调用的地方.sequential().forEach(downstream)。这表明forEach旨在保留顺序流的顺序，但也可能只是库中的错误。
forEachOrdered为了安全起见，我已经在我自己的代码中避免了这种歧义，但是今天我发现NetBeans
IDE的“使用功能操作”编辑器提示将转换为
for (Foo foo : collection) foo.bar();
进入
collection.stream().forEach((foo) -> { foo.bar();
});
如果forEach不保留遇到顺序，则会引入一个错误。在报告针对NetBeans的错误之前，我想知道该库实际上由源提供了保证。
我正在寻找 提供的
。这可能是库实现中的明确注释，关于Java开发邮件列表的讨论（Google找不到适合我的东西，但也许我不知道其中的神奇词），或者库设计者的声明（我在其中知道两个，BrianGoetz和StuartMarks在堆栈溢出中很活跃。（请不要回答“只使用forEachOrdered代替” －我已经这样做了，但是我想知道是否正确的代码是错误的。）
回答：
存在的规范描述的是调用方可以依赖的最低保证，而不是描述实现的工作。这个差距至关重要，因为它允许实现灵活性不断发展。（规范是声明性的；实现是必须的。）规范过度与规范不足同样糟糕。
当规范说“不保留属性X”时，并不表示可能永远不会观察到属性X。这意味着该实现没有义务保留它。您声称永远不会保留相遇顺序的说法是错误的结论。（HashSet不保证迭代其元素会保留它们的插入顺序，但这并不意味着这不会偶然发生-
您只是不能指望它。）
同样，您的含义“暗示forEach旨在保留顺序流的顺序”，因为您看到在某些情况下这样做是不正确的。
在这两种情况下，您似乎都不满意该规范forEach具有很大的自由度。具体地说，它具有不保留顺序流的遇到顺序的自由度，即使这是实现当前正在执行的操作，而且，很难想象实现会不按顺序处理顺序源。但这就是规范所说的，这就是要说的。
也就是说，关于并行流的注释的措词可能会造成混淆，因为仍然可能会误解它。在这里明确指出并行案例的目的是教学上的；完全删除该句子后，规范仍然非常清晰。但是，对于不了解并行性的读者，几乎不可能
不
假设它forEach会保留遇到的顺序，因此添加了这句话以帮助阐明动机。但是，正如您所指出的那样，特别对待顺序案件的愿望仍然如此强大，以至于进一步澄清将是有益的。
以上是 Stream.forEach是否遵守顺序流的遇到顺序？ 的全部内容， 来源链接： utcz.com/qa/430415.html
