能，hashmap 允许一个 null 键，通过特殊分支处理哈希计算与查找，get(null) 返回对应值或 null（无法区分不存在与值为 null），而 concurrenthashmap 因并发安全原因禁止 null 键。
HashMap.put(null, value) 能正常工作吗
能，但只允许一个 null 键存在。Java 的 HashMap 明确支持键为 null，不是靠“意外没报错”，而是代码里有专门分支处理。
内部在计算哈希值时，HashMap 对 null 键做了短路：不调用 hashCode()，直接返回 0。所以不会抛 NullPointerException —— 这和你手动调 null.hashCode() 完全不同。
-
put(null, "a")→ 存入桶索引0（因为 hash = 0，(n-1) & hash = 0） -
put(null, "b")→ 替换原null键对应的值，不会新增节点 - 多个
null键的put操作，最终只保留最后一次的值
get(null) 返回什么、怎么查到的
返回对应值，或 null（注意：无法区分“键不存在”和“键存在但值为 null”）。
查找过程跳过哈希计算：当 key == null，直接去 table[0] 链表/红黑树里遍历，逐个比对节点的 key == null（不是 equals），找到就返回 value。
立即学习“Java免费学习笔记（深入）”；
- 这个逻辑写死在
getTreeNode和getNode方法里，不走通用哈希路径 - 如果 table[0] 是红黑树，也只按
key == null判断，不调compareTo或hashCode - 所以即使自定义类重写了
hashCode抛异常，get(null)依然安全
为什么 HashMap 允许 null 键，而 ConcurrentHashMap 不允许
根本原因是并发安全模型不同：ConcurrentHashMap 放弃了对 null 键的特殊处理，是为了避免歧义和简化分段锁逻辑。
HashMap 是单线程友好结构，加一点 if 分支成本极低；ConcurrentHashMap 在每个 bin 上可能并发读写，null 键会干扰 CAS 判定、影响扩容判断、增加空指针风险点。
-
ConcurrentHashMap.put(null, v)直接抛NullPointerException -
ConcurrentHashMap.get(null)也返回null，但不是“查到了”，而是被提前拦截了 - 别试图绕过：哪怕先
put再get，只要 key 是null，第一步就失败
实际写代码时容易踩的坑
最常出问题的地方不是“能不能用”，而是“用了之后怎么判断是否存在”。因为 get(null) 返回 null 无法说明键是否存在。
- 别用
map.get(null) == null判断null键是否存过——它既可能是没存，也可能是存了null值 - 正确方式是用
map.containsKey(null)，它内部走的是专用分支，准确返回true/false - 如果 value 本身也可能为
null，又必须区分状态，那就别用null当 key，改用"__NULL_KEY__"这类哨兵字符串 - 序列化时注意：
HashMap序列化后仍保留null键，但某些 JSON 库（如 Jackson 默认）会跳过null键，导致反序列化丢失
真正麻烦的从来不是“怎么让它跑起来”，而是“怎么确认它按你想的那样在跑”。null 键的语义模糊性，在调试和协作时比性能问题更难暴露。
