What is ConcurrentHashMap? – Code With Rupendra

Definition:

ConcurrentHashMap is a thread-safe version of HashMap.
It allows concurrent read and controlled write operations without locking the entire map.

Key Points:

Thread-safe — designed for multi-threaded environments.
Uses segment or bucket-level locking (Java 8+: finer-grained locking via CAS).
Does not allow null keys or values.
High concurrency performance — multiple threads can read/write simultaneously.
Iterators are fail-safe — they do not throw exceptions during concurrent modification.
Part of the java.util.concurrent package.
Suitable for highly concurrent applications like caches, shared state maps, etc.

Question 1- How many thread can write and read at a same time?

How many threads can read and write concurrently depends on the Java version.

⚙️ Java 8 and Later (Most Common Case)

Since Java 8, ConcurrentHashMap uses a lock-free and fine-grained locking approach (via CAS — Compare-And-Swap and Node-level synchronization).

✅ Reading:

Any number of threads can read simultaneously.
→ Reads are non-blocking (no locks for reading).

✅ Writing:

Multiple threads can write concurrently, as long as they write to different buckets (segments).
If two threads try to update the same bucket, only one will lock that bucket while the other waits.

So, effectively:

Concurrent Reads → Unlimited
Concurrent Writes → Up to the number of independent buckets (typically the map’s internal concurrency level).

In Java 8, this concurrency level dynamically adapts — but roughly you can think:

“One write lock per hash bucket” (so writes to different buckets can proceed in parallel).

🧮 Before Java 8 (Java 7 and earlier)

Internally divided into segments (default 16).
Each segment had its own lock.

So:

Up to 16 threads could write concurrently (each on a separate segment).
Unlimited reads (except when reading from a locked segment).

🧩 Summary Table

Operation	Java 7 and Earlier	Java 8 and Later	Explanation
Read Threads	Unlimited	Unlimited	Reads are non-blocking
Write Threads	Up to 16 (default concurrency level)	Many (depends on buckets & collisions)	Locks at segment/bucket level
Read + Write Together	Allowed	Allowed	Readers not blocked by writers except rare conflicts

Question 2- Can ConcurrentHashMap have null keys or values? Why not?

Answer:
No.
Because ConcurrentHashMap can’t distinguish whether a null value means:

The key is not present, or
The key is mapped to null.
This ambiguity could break thread-safety during concurrent operations.

Question 3- How does ConcurrentHashMap achieve thread safety?

Answer:
It uses a fine-grained locking mechanism:

In Java 7, it divided the map into segments, each with its own lock.
In Java 8 and later, it uses CAS (Compare-And-Swap) operations and synchronized blocks at the bucket (bin) level, reducing lock contention.

Question 4- What is the concurrency level in ConcurrentHashMap?

Answer:
It defines the estimated number of threads that can update the map concurrently.

In Java 7, you could set it via the constructor (default = 16).
In Java 8, it’s no longer a fixed parameter; the implementation handles concurrency dynamically using finer-grained locks.

Question 5- What happens if multiple threads write to the same bucket?

Answer:
Only one thread can lock a bucket (bin) at a time during structural modifications.
Other threads attempting to modify the same bucket will wait or use CAS retries, ensuring thread safety.

Question 6- What happens when size increases beyond threshold?

Answer:

Map resizes itself (doubles capacity).
Threads help in migration.
The resizing process is non-blocking (other operations can continue).

Question 7- Is ConcurrentHashMap faster than synchronizedMap()?

Answer:
Yes.
Because Collections.synchronizedMap() locks the entire map for every operation, while ConcurrentHashMap locks only specific buckets or uses CAS, allowing higher concurrency.

Question 8- Does ConcurrentHashMap guarantee ordering of elements?

Answer:
No, it doesn’t.
The order of keys and values is not predictable and can change during concurrent modifications.

Question 9- What happens if two threads call put() for the same key simultaneously?