ConcurrentNavigableMapのJavaDoc では、次の点について少し混乱しています。
ビューのイテレータは、ConcurrentModificationException を決してスローしない「弱い一貫性のある」イテレータであり、イテレータの構築時に存在していた要素をトラバースすることを保証し、構築後の変更を反映する場合があります (ただし保証はされません)。
ConcurrentSkipListMap のようなインターフェースの実装では、言葉遣いは同じようです。
これはどういう意味ですか、矛盾しているように見えます-構築時に存在する要素をトラバースすることを保証できるか、または構築後の変更を反映する可能性がありますか??
更新: 基本的に、ConcurrentSkipListMap のような ConcurrentNavigableMaps でイテレータを作成すると、マップの「スナップショット」ビューが作成されるかどうかを知りたいです。
私自身の質問に答えるために、イテレータによって提供される一貫性の保証の強さについての議論が、並行性に関するメーリング リストのこちらにあります。
ConcurrentHashMap と ConcurrentSkipListMap の作成者である Doug Lea は、保証はまったく保証されていないことに同意しているようで、ConcurrentHashMap の場合、反復子はマップが実際にはなかった状態にあると報告できることに同意しているようです。 .
好奇心旺盛な方のために、ConcurrentSkipListMap のソース、具体的にはその内部 Iter (反復子) クラスはhereです。
ConcurrentSkipListMap の反復子は、スキップ リスト内の通常のノードを反復し、それらのノードは揮発性参照を使用してリンクされます。このやや紛らわしい JavaDoc ステートメントは、実際には [単純に] 事前発生保証を参照している可能性があります。つまり、イテレータを作成する前に他のスレッドによって行われた変更は、イテレーションを駆動するスレッドに表示されるだけです。
言い回しは奇妙ですが、実際には、イテレータの構築後に加えられた変更の一部がイテレータに反映される可能性がありますが、それらすべてが反映されるとは限りません。これらの反映された変更を除いて、要素は構築時に存在していたとおりにトラバースされます。
実際には、(大まかに) 一貫性の低いイテレータがコレクションをトラバースするため、既にトラバースされたコレクションの部分の変更を反映することはできませんが、まだトラバースされていないコレクションの部分の変更を反映することを意味します。