Hashtable 一放 null 就抛 NullPointerException，因其所有 public 修改方法均在执行时立即调用 Objects.requireNonNull(key/value)，将键值非空作为设计契约；containsKey(null) 和 containsValue(null) 则始终返回 false。
为什么 Hashtable 一放 null 就抛 NullPointerException
Hashtable 在构造时就硬编码了对 null 的拒绝逻辑——不是延迟检查，是每次 put、get、remove 都先调 Objects.requireNonNull(key) 和 Objects.requireNonNull(value)。这不是 bug，是设计契约：它把「键值非空」当作容器成立的前提条件。
常见错误现象：NullPointerException 报错堆栈里总出现 Hashtable.put 或 Hashtable.get，但你没显式传 null？那大概率是上游方法返回了 null（比如 map.get("x") 没命中），你直接塞进了 Hashtable。
- 所有 public 修改方法（
put、putAll、remove）都会立即校验，不等扩容或 rehash -
containsKey(null)和containsValue(null)不抛异常，但永远返回false—— 因为根本存不进去 - 注意：
new Hashtable<>()本身不校验，问题出在第一次put
Hashtable 的线程安全到底靠什么实现
它用的是方法级 synchronized：每个 public 方法（get、put、size 等）都锁住整个实例对象。这意味着并发读写不会出错，但代价是吞吐量低——哪怕两个线程操作完全不重叠的 key，也得排队。
使用场景有限：只适合读多写少、数据量小、且无法升级 JDK 的遗留系统。JDK 5 后基本被 ConcurrentHashMap 取代。
立即学习“Java免费学习笔记（深入）”；
-
get也是同步的，这点和ConcurrentHashMap不同（后者允许无锁读） - 迭代器是「fail-fast」的，但因为全表锁，实际很少触发
ConcurrentModificationException - 扩容时会锁整个表，期间所有读写阻塞 —— 大表扩容可能卡几百毫秒
替代 Hashtable 时要注意哪些兼容性断点
直接换成 ConcurrentHashMap 看似合理，但有三个关键行为差异必须处理：
-
ConcurrentHashMap允许null值（但不允许null键），而Hashtable键值都不允许 —— 如果旧代码依赖「get返回null一定表示不存在」，换成ConcurrentHashMap后需补判containsKey -
Hashtable.keys()返回Enumeration，ConcurrentHashMap.keySet()返回Set—— 迭代写法要改，比如while (e.hasMoreElements())得转成增强 for -
Hashtable的size()是精确值（锁表后数），ConcurrentHashMap.size()是估算值（可能滞后）—— 如果业务逻辑依赖实时精确大小（如限流判断），不能直接替换
如果必须用 Hashtable，怎么安全地做 null 防御
别指望绕过它的 null 检查——反射、继承重写都破坏封装且不可靠。正确做法是在进容器前拦截：
- 用
Objects.requireNonNullElse(key, "MISSING")提供默认键（需确保默认键不冲突） - 对 value 做空转义：
value == null ? NULL_PLACEHOLDER : value，其中NULL_PLACEHOLDER是你定义的哨兵对象 - 更稳妥的是加一层薄包装类，把
put方法改成：if (key == null || value == null) throw new IllegalArgumentException("null not allowed"); else super.put(key, value);
容易踩的坑：有人试图用 Optional.ofNullable(value).orElseThrow()，但这只是把 NPE 换成 IAE，没解决根本问题；还有人想用 try-catch 捕获 NullPointerException，但这是反模式——异常不该用于流程控制。
真正麻烦的从来不是语法限制，而是老系统里那些没文档的隐式假设：比如某个 key 为空时本该走默认分支，结果被 Hashtable 拦在门外，错误被掩盖成别的异常。这种地方，光看代码看不出问题，得翻调用链上三层。
