"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. 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. "

It's particularly difficult to come up with examples that illustrate timing issues in multithreaded applications. I can't think of an easy example that would demonstrate that puts don't block gets in a ConcurrentHashMap. More importantly, examples are not conclusive in multithreaded applications. That some behavior didn't occur in an example doesn't mean it can't occur in general.

Assuming your question is:

sandy sean wrote:But suppose one thread is writing(put()) to a bucket then, can second thread simultaneously read(get()) from the same bucket or second thread will have to wait for the put operation to get completed?

then the answer would probably be

Citing the documentation, koilraj abraham wrote:Retrieval operations (including get) generally do not block, so may overlap with update operations (including put and remove).

Luan Cestari wrote:Just for curiosity, the Collections.synchronizedMap() ... does behave exactly what you thought about ConcurrentHashMap in first place

Just to clarify - the OP was aware that ConcurrentHashMap supports concurrent reads (gets). He asked whether reads are blocked by writes.

The ConcurrentHashMap class supports the concept of segmentation, which allows different segments to be worked upon separately. This allows parallel writes -- or even writes with reads. Unfortunately, this is an implementation detail, and is not documented to behave in a particular way. So, whether reads are blocked by writes? I guess the answer is that it depends.