concurrenthashmap 不允许 key 或 value 为 null，是为了避免多线程下 get 返回 null 时语义二义性（无法区分键不存在还是值为 null），并保持与 hashtable 一致的行为；源码通过 putval 开头的空值校验强制拦截，推荐用哨兵对象替代 null。
ConcurrentHashMap 不允许 key 或 value 为 null，核心是为了在多线程环境下保证操作语义的明确性和结果的可判定性。这不是疏漏，而是刻意设计。
根本原因：null 会导致语义二义性
当 get(key) 返回 null 时，你无法判断这是：
- key 根本不存在；
- 还是 key 存在，但对应 value 确实是
null。
单线程的 HashMap 可以靠 containsKey() 辅助判断，但在并发场景下，containsKey() 和 get() 之间可能被其他线程修改——比如刚查完“不存在”，另一线程就 put(key, null)，导致逻辑错乱。这种不确定性在高并发业务中极易引发重复初始化、缓存穿透或状态误判。
与 Hashtable 保持行为一致
ConcurrentHashMap 是作为线程安全的 Hashtable 替代品设计的。Hashtable 同样禁止 null key/value，原因类似：key 为 null 会直接触发 key.hashCode() 抛出 NullPointerException；value 为 null 则在 put 中显式校验并拒绝。ConcurrentHashMap 延续了这一契约，确保迁移和替换时行为可控。
源码强制校验，杜绝绕过可能
从 JDK 8 到最新版本，putVal() 方法开头就包含严格检查：
if (key == null || value == null)
throw new NullPointerException();
这个校验发生在任何并发逻辑之前，既防止空指针在后续哈希计算或节点操作中引发不可预期异常，也从根源上封堵了二义性入口。不是“忘了支持”，而是主动拦截。
替代方案简单可行
如果业务确实需要表达“空值”含义，推荐用一个静态哨兵对象代替，例如：
private static final String NULL_VALUE = "NULL_VALUE";
map.put("key", NULL_VALUE); // 而非 null
这样读取时只需比较引用，语义清晰、线程安全、无歧义。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
