Spliterator：线程安全与否？答案

【问题标题】：Spliterator: Thread-Safe or not?Spliterator：线程安全与否？
【发布时间】：2018-01-09 12:19:26
【问题描述】：

我正在查看 Spliterator 的文档，根据它，Spliterator 不是线程安全的：

尽管在并行算法中有明显的实用性，但分离器并不期望是线程安全的；相反，使用拆分器的并行算法的实现应确保拆分器一次仅由一个线程使用。这通常很容易通过串行线程限制实现，这通常是通过递归分解工作的典型并行算法的自然结果。

但是，在其进一步的文档中，与上述声明相矛盾：

可以通过以下方式管理源的结构干扰（按合意性递减的大致顺序）：

源管理并发修改。例如，java.util.concurrent.ConcurrentHashMap 的键集是一个并发源。从源创建的 Spliterator 报告了 CONCURRENT 的特征。

那么这是否意味着从线程安全集合生成的 Spliterator 将是线程安全的？对吗？

【问题讨论】：

我认为这两个陈述没有矛盾：Spliterator 不需要是线程安全的，但它可以是线程安全的。如果它是线程安全的，它可能会报告它具有CONCURRENT 特征。

标签： java-8 iterator thread-safety java-stream spliterator

【解决方案1】：

不，报告CONCURRENT 特性的Spliterator 将具有线程安全源，这意味着即使源被同时修改，它也可以安全地迭代它。但是Spliterator 本身可能仍然具有不能同时操作的状态。

请注意，您的引用源于对“如何管理源的结构干扰”的描述，而不是关于分离器的一般行为。

documentation of the CONCURRENT characteristic itself 也提供此信息：

表示元素源可以被多个线程安全地同时修改（允许添加、替换和/或删除）的特征值，而无需外部同步。如果是这样，Spliterator 应该有一个关于遍历期间修改的影响的文档化策略。

没有别的了。

因此，这些特征的后果小得惊人。 Spliterator 报告 CONCURRENT 或 IMMUTABLE 永远不会抛出 ConcurrentModificationException，仅此而已。在所有其他方面，Stream API 不会识别这些特征之间的差异，因为Stream API 从不执行任何源操作，事实上，它实际上并不知道源（除了通过Spliterator)，因此它无法进行此类操作，也无法检测是否发生了并发修改。

【讨论】：