ConcurrentNavigableMap,解释弱一致的迭代器

时间:2011-11-06 03:43:42

标签: java iterator concurrenthashmap concurrent-collections

JavaDoc for ConcurrentNavigableMap中,我对以下内容感到有些困惑:

  

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

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

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

更新:我基本上想知道在ConcurrentNavigableMaps上创建迭代器(如ConcurrentSkipListMap)是否会创建地图的“快照”视图。

2 个答案:

答案 0 :(得分:4)

为了回答我自己的问题,我们讨论了迭代器在并发兴趣邮件列表here上提供的一致性保证的强度。

ConcurrentHashMap和ConcurrentSkipListMap的作者,Doug Lea,appears to agree,保证完全没有保证,并且在ConcurrentHashMap的情况下,迭代器可以报告地图处于一种状态:从来没有 实际上在。

对于那些好奇的人来说,ConcurrentSkipListMap的来源,特别是它的内部Iter(迭代器)类是here

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

答案 1 :(得分:2)

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

在实践中,它(大致)表示由于弱一致的迭代器遍历集合,它不能反映已遍历的集合部分的变化,但反映了尚未遍历的集合部分的变化。