为什么不推荐基于 AtomicInteger 的 Stream 解决方案？

Question

假设我有这份水果清单：-

List<String> f = Arrays.asList("Banana", "Apple", "Grape", "Orange", "Kiwi");

我需要在每个水果前面加上一个序列号并打印出来。水果的顺序或序列号无关紧要。所以这是一个有效的输出：-

4. Kiwi
3. Orange
1. Grape
2. Apple
5. Banana

解决方案 #1

AtomicInteger number = new AtomicInteger(0);

String result = f.parallelStream()
        .map(i -> String.format("%d. %s", number.incrementAndGet(), i))
        .collect(Collectors.joining("\n"));

解决方案 #2

String result = IntStream.rangeClosed(1, f.size())
        .parallel()
        .mapToObj(i -> String.format("%d. %s", i, f.get(i - 1)))
        .collect(Collectors.joining("\n"));

问题

为什么解决方案 #1 是不好的做法？我在很多地方都看到基于AtomicInteger 的解决方案不好（比如this answer），特别是在并行流处理中（这就是我在上面使用并行流来尝试遇到问题的原因）。

我查看了这些问题/答案：-
In which cases Stream operations should be stateful?
Is use of AtomicInteger for indexing in Stream a legit way?
Java 8: Preferred way to count iterations of a lambda?

他们只是提到（除非我错过了什么）“可能会出现意想不到的结果”。像什么？在这个例子中会发生吗？如果没有，你能举个例子吗？

至于“不保证映射器函数的应用顺序”，嗯，这就是并行处理的本质，所以我接受它，而且顺序不在这个特定的例子中无关紧要。

AtomicInteger 是线程安全的，所以在并行处理中应该不是问题。

有人可以提供示例，在哪些情况下使用这种基于状态的解决方案会出现问题？

Answer 1

看看 Stuart Marks here 的答案是什么 - 他正在使用有状态谓词。

这是几个潜在的问题，但如果你不关心它们或真正理解它们 - 你应该没问题。

首先是顺序，在并行处理的当前实现下展示，但如果您不关心顺序，就像在您的示例中一样，您可以。

第二个是潜在的速度AtomicInteger 将慢几倍，如前所述，增加一个简单的 int，如果你关心这个。

第三个更微妙。有时根本无法保证 map 会被执行，例如从 java-9 开始：

 someStream.map(i -> /* do something with i and numbers */)
           .count();

这里的重点是，由于您正在计数，因此无需进行映射，因此跳过了。通常，不能保证命中某些中间操作的元素到达终端之一。想象一下map.filter.map 的情况，与第二个相比，第一个映射可能“看到”更多元素，因为某些元素可能被过滤掉了。所以不建议依赖这个，除非你能准确地推断出发生了什么。

在你的例子中，IMO，你做你所做的事是非常安全的；但是如果你稍微改变你的代码，这需要额外的推理来证明它的正确性。我会选择解决方案 2，因为它对我来说更容易理解，并且没有上面列出的潜在问题。

Answer 2

另请注意，尝试从行为参数访问可变状态会使您在安全和性能方面做出错误的选择；如果您不同步对该状态的访问，您就会遇到数据竞争，因此您的代码会被破坏，但是如果您确实同步对该状态的访问，您可能会因为争用而破坏您正在寻求从中受益的并行性。 最好的方法是避免有状态的行为参数来完全流式操作；通常有一种方法可以重组流管道以避免有状态。

^{Package java.util.stream, Stateless behaviors}

从线程安全性和正确性的角度来看，解决方案 1 没有任何问题。但性能（作为并行处理的优势）可能会受到影响。

---

为什么解决方案 #1 是不好的做法？

我不会说这是一种不好的做法或不可接受的东西。为了性能，根本不推荐。

他们只是提到（除非我错过了什么）“可能会出现意想不到的结果”。比如什么？

“意外结果”是一个非常宽泛的术语，通常指不正确的同步，“到底发生了什么？”之类的行为。

在这个例子中会发生吗？

事实并非如此。您可能不会遇到问题。

如果没有，你能举个例子吗？

将AtomicInteger 更改为int*，将number.incrementAndGet() 替换为++number，您将拥有一个。

---

^{*a boxed int（例如，基于包装器、基于数组），因此您可以在 lambda 中使用它}

Answer 3

案例 2 - 在 IntStream 类的 API 注释中，通过 1 种 for 循环的增量步骤返回从 startInclusive（包含）到 endInclusive（包含）的顺序有序 IntStream，因此并行流正在逐个处理它并提供正确的顺序。

 * @param startInclusive the (inclusive) initial value
 * @param endInclusive the inclusive upper bound
 * @return a sequential {@code IntStream} for the range of {@code int}
 *         elements
 */
public static IntStream rangeClosed(int startInclusive, int endInclusive) {

案例 1 - 很明显，列表将被并行处理，因此顺序将不正确。由于映射操作是并行执行的，由于线程调度的差异，相同输入的结果可能因运行而异无法保证映射器函数如何也应用于流中的特定元素。

Source Java Doc