ConcurrentNavigableMap，解释弱一致的迭代器

Question

在ConcurrentNavigableMap的JavaDoc中 ，我对以下内容感到有点困惑：

视图的迭代器是一个“弱一致”的迭代器，它永远不会抛出ConcurrentModificationException，并保证遍历构造迭代器时存在的元素，并且可能（但不保证）反映构造之后的任何修改。

在ConcurrentSkipListMap等接口的实现中，措辞似乎相同。

这意味着什么，它似乎是一个矛盾 - 要么它可以保证遍历构造时存在的元素，要么它可能反映了构造后的修改？

更新：我基本上想知道是否在ConcurrentNavigableMaps上创建一个像ConcurrentSkipListMap的迭代器，创建一个地图的“快照”视图。

Answer 1

要回答我的问题，有一个由迭代器并发利益邮件列表上提供的一致性保证强度的讨论在这里 。

ConcurrentHashMap和ConcurrentSkipListMap的作者Doug Lea 似乎同意保证完全没有保证，并且在ConcurrentHashMap的情况下，迭代器可以报告映射处于从未实际存在的状态。 。

对于那些好奇的人来说，ConcurrentSkipListMap的来源，特别是它的内部Iter（迭代器）类就在这里 。

ConcurrentSkipListMap中的迭代器迭代跳过列表中的常规节点，并使用易失性引用链接这些节点。 可能是这种有点令人困惑的JavaDoc语句实际上[简单地]指的是先发生的保证。 即，在创建迭代器之前由其他线程进行的更改将仅对驱动迭代的线程可见。

Answer 2

措辞很奇怪，但实际上它意味着迭代器可能反映了构造迭代器后所做的一些更改，但并不能保证反映所有这些更改。 除了这些反映的变化之外，元素在构造时存在。

在实践中，它（大致）表示由于弱一致的迭代器遍历集合，它不能反映已经遍历的集合部分的变化，而是反映尚未遍历的集合部分的变化。