我正在查看 Spliterator 的文档，根据它，Spliterator 不是线程安全的：
尽管它们在并行算法中有明显的用途，但分离器并不期望是线程安全的。相反，使用拆分器的并行算法的实现应确保拆分器一次仅由一个线程使用。这通常很容易通过串行线程限制来实现，这通常是通过递归分解工作的典型并行算法的自然结果。
但是，在其进一步的文档中，与上述声明相矛盾：
可以通过以下方式管理源的结构干扰（按合意性递减的大致顺序）：
源管理并发修改。例如，java.util.concurrent.ConcurrentHashMap 的键集是一个并发源。从源创建的 Spliterator 报告 CONCURRENT 的特征。
那么这是否意味着从线程安全集合生成的 Spliterator 将是线程安全的？这样对吗？
不，Spliterator报告CONCURRENT特性将具有线程安全源，这意味着即使源被同时修改，它也可以安全地迭代它。但是它Spliterator本身可能仍然具有不能同时操作的状态。
请注意，您的引用源于对“如何管理源的结构干扰”的描述，而不是关于分离器的一般行为。
这也在特性本身的文档中CONCURRENT提供：
特征值表示元素源可以被多个线程安全地同时修改（允许添加、替换和/或删除）而无需外部同步。如果是这样，Spliterator 应该有一个关于遍历期间修改的影响的文档化策略。
没有其他的。
所以这些特征的后果是惊人的小。报告Spliterator要么CONCURRENT或IMMUTABLE永远不会抛出ConcurrentModificationException，仅此而已。在所有其他方面，API 不会识别这些特征之间的差异Stream，因为StreamAPI 从不执行任何源操作，事实上，它实际上并不知道源（除了通过 间接Spliterator），所以它不能t 执行此类操作，也不会检测是否发生了并发修改。