Why ConcurrentHashMap Disallows Null Keys and Values in Java

In Java, the thread‑safe collection ConcurrentHashMap does not permit null keys or values, whereas the non‑thread‑safe HashMap allows them. This article explains the reasoning behind that design choice.

The put method of ConcurrentHashMap checks both the key and the value for null and throws a NullPointerException if either is null.

Doug Lea, the original author of the class, clarified the main reason in an email: allowing nulls would introduce ambiguities that are tolerable only in non‑concurrent maps. Specifically, if map.get(key) returns null, a concurrent map cannot reliably tell whether the key is absent or explicitly mapped to null, because a separate containsKey check could be invalidated by concurrent modifications.

Lea also expressed a broader opinion that permitting nulls in maps (and sets) invites subtle bugs that may surface at unpredictable times, a design issue he has debated with other Java experts.

In a single‑threaded scenario, one can safely use containsKey to differentiate between a missing entry and a null value. In a multithreaded environment, however, concurrent updates make such a check unreliable, leading to the ambiguity that could compromise thread safety.

Conclusion: The prohibition of null keys and values in ConcurrentHashMap is a deliberate design decision to avoid ambiguous states in concurrent contexts, thereby preserving the collection’s thread‑safety guarantees.