线程安全需权衡性能：Hashtable全方法同步但低效，HashMap无锁但多线程写不安全；推荐ConcurrentHashMap或按场景选synchronizedMap；null处理、容量设计、迭代器行为及JDK9+弃用均为关键差异。
线程安全不是“开了就稳”，而是代价明确
Hashtable 的每个 public 方法都加了 synchronized，看起来省心，但实际是把整张表锁死了——哪怕你只 get 一个 key，其他线程也得排队。HashMap 完全不锁，单线程下快得多，但多线程写入（比如两个线程同时 put）可能触发扩容重哈希，导致死循环（JDK 7）或数据丢失（JDK 8+）。这不是“能不能用”的问题，而是“你愿不愿意为线程安全多付 2–5 倍性能开销”。
实操建议：
- 确定是纯读场景？用
Collections.synchronizedMap(new HashMap())比 Hashtable 更轻量（只锁方法，不锁整个类） - 真要高并发写？直接换
ConcurrentHashMap，它分段锁 + CAS，吞吐量远超 Hashtable - 别在 Spring Bean 里把 HashMap 当全局缓存用——没同步机制，多个请求并发 put 可能悄悄丢数据
null 键和 null 值：不是“支持与否”，而是“抛不抛异常”
HashMap 允许一个 null 键（内部用特殊桶存储）、任意多个 null 值；Hashtable 遇到 null 键或值，立刻抛 NullPointerException。这不是设计偏好，是底层哈希计算逻辑决定的：hash(null) 在 Hashtable 中返回 0，但后续除留余数时会触发空指针；HashMap 则显式判断并走 putForNullKey 分支。
常见错误现象：
- 从数据库查出字段为 NULL 的记录，直接塞进 Hashtable → 程序 crash，堆栈里只有
NullPointerException，没提示哪一行 - 用
map.get(key)返回null，误以为 key 不存在——其实可能是 key 存在但 value 是null（HashMap 下才需额外调用containsKey确认） - JSON 反序列化时，某些库默认把缺失字段设为
null，若目标 Map 是 Hashtable，反序列化直接失败
初始容量与扩容公式：影响首次 put 的性能抖动
HashMap 默认初始容量是 16（必须是 2 的幂），扩容时翻倍（16 → 32 → 64）；Hashtable 默认是 11，扩容公式是 old * 2 + 1（11 → 23 → 47 → 95）。这不只是数字差异：HashMap 的 2 的幂容量配合位运算（h & (length-1)）比 Hashtable 的取模（h % length）快一个数量级；而 Hashtable 的奇数扩容序列容易让哈希分布更散，但代价是每次扩容都要重新计算所有 entry 的位置——且无法利用 CPU 的位操作优化。
实操建议：
- 预估数据量 > 1000 条？HashMap 初始化时指定容量（如
new HashMap(2048)），避免多次 resize - Hashtable 如果硬要用，别依赖默认 11，手动设成质数（比如 997）能略微改善冲突率，但治标不治本
- 别在循环里反复 new HashMap() 却不设初始大小——小对象 GC 压力小，但频繁扩容的哈希重分布成本很高
迭代器行为差异：遍历时删元素，结果可能完全不同
HashMap 的 Iterator 是 fail-fast 的：遍历中调用 map.remove(key) 会立即抛 ConcurrentModificationException；而 Hashtable 的 Enumeration 不检查修改，允许边遍历边删，但结果不可预测（可能漏删、重复删、甚至跳过下一个元素）。
使用场景：
- 需要安全删除？用 HashMap +
Iterator.remove()（唯一合法方式） - 旧代码还在用
hashtable.keys()或elements()？赶紧替换成keySet().iterator()，否则上线后偶发数据错乱很难复现 - ConcurrentHashMap 提供
forEach和computeIfAbsent等原子操作，比手写同步块更可靠
真正容易被忽略的点：JDK 9+ 中 Hashtable 已被标记为 @Deprecated(forRemoval = true)，不是警告，是明确计划移除。现在还用它，不是“保守”，是技术债。
