我期待到Spliterator的文件，并根据它的Spliterator是不是线程安全的：Spliterator：线程安全与否？
尽管在并行算法的明显的效用，spliterators预计不会是线程安全的;相反，使用分割器的并行算法的实现应该确保分割器一次只能由一个线程使用。这通常很容易通过串行线程约束来实现，这通常是通过递归分解工作的典型并行算法的自然结果。
但是，其进一步的文件，其中规定一个矛盾的声明，上述声明：
可以通过以下方式来管理源（按递减可取的大致顺序）的结构干扰：
源管理并发修改。 例如，java.util.concurrent.ConcurrentHashMap的键集是一个并发源。从源头创建的Spliterator报告了CONCURRENT的特征。
那么这是否意味着从线程安全集合生成的Spliterator将是线程安全的？这样对吗？
不，Spliterator报告CONCURRENT特征将有一个线程安全源，这意味着它可以迭代它安全地即使源被同时修改。但Spliterator本身可能仍然具有不能同时操纵的状态。
请注意，您的引用来源于“源的结构干扰可以如何管理”的描述，而不是一般分裂者的行为。
这也设置在documentation of the CONCURRENT characteristic itself：
特性值表示该元素源可以安全地同时修改（允许添加，替换，和/或清除）由多个线程没有外部同步。如果是这样，Spliterator预计会有一个关于遍历期间修改影响的文档化策略。
没有别的。
所以这些特点的后果是惊人的小。报告CONCURRENT或IMMUTABLE的Spliterator永远不会抛出ConcurrentModificationException，就这些。在所有其他方面，这些特征之间的差异将不会被Stream API识别，因为Stream API从不执行任何源操作，事实上，它实际上并不知道源（除了间接通过Spliterator），所以它不能做这样的操作，也不能检测是否发生了同时修改。
我在这两个语句中看不出矛盾：'Spliterator'不是线程安全的，但它可以是线程安全的。如果它是线程安全的，它可能会报告它具有'CONCURRENT'特性。 –