Spliterator:线程安全与否？

Question

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

尽管它们在并行算法中具有明显的实用性,但预计分裂器不是线程安全的.相反,使用分裂器的并行算法的实现应确保分裂器一次仅由一个线程使用.这通常很容易通过串行线程限制来实现,这通常是通过递归分解工作的典型并行算法的自然结果.

但是,在其进一步的文件中,其中陈述了对上述陈述的矛盾陈述:

源的结构干扰可以通过以下方式进行管理(大致降低合意性的顺序):

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

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

Answer 1

不,Spliterator报告CONCURRENT特征会有一个线程安全的来源,这意味着它可以迭代它安全地即使源被同时修改.但是,Spliterator它本身可能仍然具有不能同时操纵的状态.

请注意,您的引用源于对"源的结构干扰如何管理"的描述,而不是关于分裂器的一般行为.

这也在特征本身的文档中CONCURRENT提供:

表示可以在没有外部同步的情况下由多个线程安全地同时修改元素源(允许添加,替换和/或删除)的特征值.如果是这样,Spliterator应该有一个关于遍历期间修改影响的书面政策.

没有其他的.

所以这些特征的后果是惊人的小.一个Spliterator报告无论是CONCURRENT或IMMUTABLE将永远不会抛出ConcurrentModificationException,这就是全部.在所有其他方面,API不会识别这些特性之间的差异Stream,因为StreamAPI从不执行任何源操作,事实上,它实际上并不知道源(除了间接通过Spliterator),因此它不能'做这样的操作,也不检测是否发生了并发修改.