多线程下不能用HashMap替代Hashtable，因其无锁设计易致扩容死循环或数据丢失；Hashtable虽线程安全但性能差；应优先选用ConcurrentHashMap。
为什么多线程下不能用 HashMap 替代 Hashtable
因为 HashMap 完全不加锁，多线程并发写入时可能触发扩容导致链表成环（JDK 7）或数据丢失（JDK 8 虽修复死循环，但仍不保证原子性），而 Hashtable 所有方法都用 synchronized 修饰，是“方法级全局锁”——虽然线程安全，但吞吐量极低，高并发时大量线程阻塞在同一个锁上。
- 现象：两个线程同时调用
put()，HashMap可能返回null、丢数据、甚至 CPU 占用飙到 100% - 误区：以为加个
Collections.synchronizedMap(new HashMap())就够了——它也是全局锁，性能和Hashtable基本一致 - 正解：真要线程安全，直接用
ConcurrentHashMap，读操作无锁，写操作只锁单个桶节点
null 键和 null 值到底能不能存
HashMap 允许一个 null 键（哈希值固定为 0，存在数组索引 0 处）和任意多个 null 值；Hashtable 对两者都严格禁止，一存就抛 NullPointerException。
- 典型踩坑：从配置加载 key 为字符串的 map，若某配置项为空，
HashMap能存，Hashtable直接崩溃 - 兼容性影响：旧代码迁移到新框架时，如果用了
Hashtable并依赖其 null 检查逻辑，换成HashMap后可能掩盖空指针问题 - 注意：
ConcurrentHashMap也不允许null键，但允许null值——这点和HashMap不同
底层结构和扩容机制差异直接影响性能
JDK 1.8+ 的 HashMap 是“数组 + 链表 + 红黑树”，当链表长度 ≥ 8 且数组容量 ≥ 64 时自动转红黑树，查询从 O(n) 降到 O(log n)；Hashtable 始终只有数组 + 链表，无树化优化，大数据量下冲突链过长会明显拖慢 get/put。
- 初始容量：
HashMap默认 16（2 的幂，用hash & (capacity - 1)快速定位桶）；Hashtable默认 11（奇数，老式取模hash % capacity） - 扩容公式：
HashMap新容量 = 旧容量 × 2；Hashtable新容量 = 旧容量 × 2 + 1 - 哈希扰动：
HashMap对hashCode()做二次异或（h ^ (h >>> 16)），降低低位重复导致的哈希碰撞；Hashtable直接用原始hashCode()
别再继承 Dictionary 或用 elements() 这类遗留 API
Hashtable 继承自已废弃的 Dictionary 抽象类，还保留 elements() 和 keys() 方法，返回 Enumeration；而 HashMap 是标准集合框架一员，统一用 Iterator，支持 forEach、computeIfAbsent 等函数式操作。
立即学习“Java免费学习笔记（深入）”；
- 后果：
Enumeration无法和 Stream 配合，也不能用增强 for 循环（必须 while + hasMoreElements()） - 迭代器行为：
HashMap迭代器是 fail-fast 的，结构被并发修改立刻报ConcurrentModificationException；Hashtable迭代器不是，出问题更难定位 - 实际建议：新项目里看到
Hashtable，优先替换为ConcurrentHashMap；若只是单线程场景，HashMap就足够，别为“线程安全”背历史包袱
真正容易被忽略的是：即使你没显式多线程操作，某些框架（如 Spring BeanFactory、Servlet 容器初始化）可能并发访问 Map 实例——这时候用错类型，问题会延迟暴露，排查成本远高于一开始选对。
