Question

The ConcurrentHashMap provides thread-safe but the docs state:

” However, even though all operations are thread-safe, retrieval operations do not entail locking”

So from this I understand that getting or setting a key and value are thread-safe, but modifying the actual VALUE of any given key isn’t (by value I actaully mean the value or state of that object).

I’m just confused on how this works, at the moment I think things work like this.

The ConcurrentHashMap only gaurantees the key’s are thread-safe in terms setting/getting them. But the object you put inside the map has to gaurd for concurrency by itself.

Is this correct?

Answer 1

But the object you put inside the map has to gaurd for concurrency by itself.

Your understanding is correct.

From the documentation:

However, even though all operations are thread-safe, retrieval operations do not entail locking, and there is not any support for locking the entire table in a way that prevents all access.

What the above is also saying is that there is no built-in mechanism for automatic locking of the hash map while the reading takes place. In particular, this means that get() operations can overlap with concurrent modifications performed by other threads.

The document goes on to explain the concurrency semantics:

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.