CODEWITHSUNDEEP
javamultithreadingdictionary
St.Antario
St.Antario

Reputation: 27385

Understanding concurrentHashMap

As known, the ConcurrenthashMap class allows us to use iterators safely. As far as I understood from the sources of the Map it's achieved by storing the current Map state into the iterator itself. Here is the inner class representing the iterator (There's a child that is created when iterator()'s called):

abstract class HashIterator {
        int nextSegmentIndex;
        int nextTableIndex;
        HashEntry<K,V>[] currentTable;
        HashEntry<K, V> nextEntry;
        HashEntry<K, V> lastReturned;

        //Methods and ctor
}

But what if some thread writes to the Map something during construction of the iterator? Do we get non-determenistic state of the map then?

The thing is neither of the methods of the Map are synchronized. There's a ReentrantLock for put method, but that's it (as far as I could find). So, I don't understand how the iterator can support a correct state even if some thread writes to the map during its construction?.

Upvotes: 1

Views: 119

Answers (2)

akhil_mittal
akhil_mittal

Reputation: 24157

From the java doc of ConcurrentHashMap:

Retrieval operations (including get) generally do not block, so may overlap with update operations (including put and remove). Retrievals reflect the results of the most recently completed update operations holding upon their onset. For aggregate operations such as putAll and clear, concurrent retrievals may reflect insertion or removal of only some entries. Similarly, Iterators and Enumerations return elements reflecting the state of the hash table at some point at or since the creation of the iterator/enumeration. They do not throw ConcurrentModificationException. However, iterators are designed to be used by only one thread at a time.

Now answering the questions.

But what if some thread writes to the Map something during construction of the iterator?

As mentioned, an iterator represents the state at some point of time. So it may not be the most recent state.

how the iterator can support a correct state even if some thread writes to the map during its construction?

The guarantee is that things will not break if you put/remove during iteration. However, there is no guarantee that one thread will see the changes to the map that the other thread performs (without obtaining a new iterator from the map). The iterator is guaranteed to reflect the state of the map at the time of it's creation. Futher changes may be reflected in the iterator, but they do not have to be.

Upvotes: 2

Peter Lawrey
Peter Lawrey

Reputation: 533510

The Iterator offers a weakly consistent state. It doesn't offer a transactional view of the data. It only offers that you will see all the keys/values if it is not altered and if it is, you may or may not see that change, but you won't get an error.

Upvotes: 3

Related Questions