ConcurrentHashMap禁止null键值是为了避免并发场景下的语义二义性：get(key)==null时无法区分key不存在还是value为null，而多线程下containsKey等辅助判断不可靠；源码中putVal首行即校验并抛NPE，确保所有写入路径统一防御。
ConcurrentHashMap 明确禁止 key 和 value 为 null，这不是疏漏或限制，而是基于并发安全、语义一致性和 API 可靠性三重考量的主动设计。
核心原因：避免“null 二义性”在并发场景下失控
在单线程容器（如 HashMap）中，get(key) == null 虽然也存在歧义（是 key 不存在？还是 value 确实为 null？），但可通过 containsKey(key) 或 containsValue(null) 配合判断——前提是数据不被其他线程修改。而 ConcurrentHashMap 的本质是**多线程安全且无全局锁**，两次方法调用之间状态可能已变：
- 线程 A 调用
get(key)得到null - 线程 B 此时执行
put(key, null)或remove(key) - 线程 A 再调用
containsKey(key)，结果可能为true或false，完全取决于时序 - 业务逻辑无法据此做出确定性决策，比如误判“key 不存在”而重复初始化，或漏处理真实存在的
null值
源码层面：校验前置且不可绕过
所有写入入口（put、putIfAbsent、compute、merge 等）最终都调用 putVal。该方法第一行就是硬性检查：
这个判断发生在任何哈希计算、桶定位、CAS 尝试或锁获取之前，不依赖 table 是否初始化、是否扩容、是否加锁——它是一道纯逻辑防火墙。
立即学习“Java免费学习笔记（深入）”；
-
key == null会导致key.hashCode()抛 NPE，且无法参与哈希分段和定位，破坏底层数据结构基础 -
value == null不影响定位，但直接瓦解“get返回null即表示缺失”的契约，使replace、computeIfAbsent、containsValue等方法逻辑失效
对比视角：为什么 HashMap 可以，ConcurrentHashMap 不行？
HashMap 允许 null 是因其设计目标是单线程高效，可接受一定语义模糊，并通过特殊处理（如 null key 固定哈希值为 0）维持基本可用；而 ConcurrentHashMap 的设计哲学是“**并发语义必须确定、可推理、不依赖调度顺序**”。Doug Lea 明确指出：非并发 Map 中勉强可容忍的歧义，在并发 Map 中根本无法容纳。
- HashTable 也不允许
null，但它是通过同步块 +key.hashCode()直接调用失败来实现，属于被动防御 - ConcurrentHashMap 是主动、显式、统一的防御机制，覆盖全部写入路径，保障 API 行为稳定
实际影响：不是不能存，而是“不该存”
如果你遇到需要表达“空值语义”，推荐替代方案：
- 用
Optional<v></v>包装 value（如put(key, Optional.empty())） - 定义专用哨兵对象，如
NULL_VALUE常量 - 用布尔字段标记“是否有效”，value 本身保持非 null
- 改用支持
null的非并发容器（仅限绝对单线程场景）并自行加锁
