concurrenthashmap 不允许 value 为 null，因会破坏“null 表示缺失”的语义一致性，所有写入入口（如 putval）均在并发控制前强制校验并抛 nullpointerexception。
ConcurrentHashMap 不允许 value 为 null，一旦传入 null，会在 put、compute 等操作中直接抛出 NullPointerException。这不是运行时偶然触发的异常，而是其底层设计中**明确插入的防御性检查**，源于对并发安全与语义一致性的双重约束。
value 为 null 会破坏“null 表示缺失”的语义
ConcurrentHashMap 借用 null 值作为“键不存在”的信号（例如 get(key) 返回 null 表示未命中）。如果允许用户存入 value == null，就无法区分“key 不存在”和“key 存在但值为 null”，导致 containsKey、replace、computeIfAbsent 等方法逻辑失效。源码中所有写入入口（如 putVal）都强制校验：
if (value == null) throw new NullPointerException();- 该检查位于方法最前端，在任何 CAS、锁或哈希计算之前执行
- 即使使用
putIfAbsent或compute，只要最终要写入的 value 是 null，同样触发
核心写入方法中的显式校验点
以 JDK 8+ 的 putVal（ConcurrentHashMap.java 第 1076 行左右）为例：
- 第一行就是
if (val == null) throw new NullPointerException(); - 这个校验不依赖于 table 是否初始化、桶是否加锁、是否发生扩容——它发生在任何并发控制逻辑之前
-
put(K key, V value)、putAll(Map)、compute(K, BiFunction)、merge(K, V, BiFunction)最终都会调用putVal，因此全部受控
为什么 key 可以为 null？（对比理解）
ConcurrentHashMap 明确禁止 key 为 null（同理抛 NPE），但这是两个独立校验：
- key 为 null → 无法计算 hash，导致定位失败，破坏基本查找能力
- value 为 null → 不影响 hash 和定位，但破坏语义一致性与并发原子操作的契约
- 二者都被拒绝，但动机不同：key 涉及算法可行性，value 涉及 API 合约可靠性
排查建议：从调用栈反推源头
当看到 NullPointerException 报在 ConcurrentHashMap.put 或类似位置时：
- 查看异常栈最上层你自己的代码行，确认传入的 value 是否可能为 null（如方法返回值未判空、Optional.orElse(null)、JSON 反序列化字段缺失等）
- 注意链式调用：比如
map.put(k, service.findUser(id).getName())，若findUser返回 null，.getName()已经 NPE；但若findUser返回对象而name字段为 null，则是这里被 ConcurrentHashMap 拦下 - IDE 调试时可在
putVal方法首行打条件断点：val == null，快速捕获非法值来源
不复杂但容易忽略。 ConcurrentHashMap 的 null 检查不是 bug，是设计铁律——守住语义边界，才撑得起高并发下的行为可预测性。
