我期待到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'特性。 –