hashmap允许null键和值，因其单线程设计通过hash()中key==null?0:hashcode()绕过空指针，并用==判断null键唯一性；concurrenthashmap和hashtable为保障并发语义清晰而禁止null。
Java 的 HashMap 允许 null 作为 key 和 value，根本原因在于它的设计目标是**单线程场景下的高性能、灵活性与实用性**，而非强语义约束。它通过显式代码逻辑绕过 null 带来的运行时风险，而不是回避 null 本身。
key 为 null：靠特殊哈希处理避免崩溃
HashMap 不会直接调用 null.hashCode()（那会抛 NullPointerException），而是在 hash() 方法里做了硬编码判断：
static final int hash(Object key) { return (key == null) ? 0 : (key.hashCode() ^ (key.hashCode() >>> 16)); }- null 键的哈希值固定为 0，因此一定落在数组索引 0 的桶（
table[0]）中 - 所有对
get(null)、put(null, v)、remove(null)的操作都跳过哈希计算，直接访问table[0]并用== null判断键是否匹配 - 这就保证了即使 key 是 null，也不会触发空指针异常，且逻辑可预测
value 为 null：无技术障碍，语义由使用者定义
value 是否为 null 完全不影响 HashMap 的内部结构和查找逻辑：
- value 不参与哈希计算、不决定存储位置、不参与 equals 比较
- 允许
map.put("a", null)、map.put("b", null)同时存在，互不干扰 - 这种自由度让 HashMap 能表达“有这个键，但值尚未设置”“该字段为空”等常见业务含义
为什么 ConcurrentHashMap 和 Hashtable 不允许？
它们的限制不是技术做不到，而是出于**并发安全与语义清晰的权衡**：
-
ConcurrentHashMap放弃了对 null 的特殊路径处理——因为并发环境下，null 键在分段锁、CAS 操作、哈希扰动等环节容易引入歧义或额外分支，增加实现复杂度和出错概率 -
Hashtable的put()方法直接写死判空：if (value == null) throw new NullPointerException()，且未对 key 做null安全包装，所以一碰就崩 - 二者都选择“禁止 null”来简化契约、提升 API 的确定性，尤其在多线程共享场景下，避免因 null 引发的隐蔽竞态或调试困难
注意：允许 ≠ 推荐盲目使用
虽然语法上合法，但用 null 当 key 或 value 会带来实际困扰：
-
get(key) == null无法区分“键不存在”和“键存在但值为 null”，必须搭配containsKey(key)或getOrDefault(key, defaultValue) - 序列化时（如 Jackson 默认配置）可能丢弃 null 键，导致数据不一致
- 多人协作或对接外部系统时，null 键易引发理解偏差；建议优先用明确哨兵值（如
"MISSING"）替代
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
