HashMap与Hashtable的核心区别在于时代背景与设计哲学：前者是JDK1.2集合框架下的现代标准实现，支持泛型、null键值、非同步及红黑树优化；后者是JDK1.0遗留类，继承Dictionary、拒绝null、全表同步且无后续演进。
HashMap 和 Hashtable 的区别，核心不在“功能相似”，而在于它们诞生于不同年代、承载不同设计哲学。理解它们，关键不是背对比条目，而是看清 Java 集合框架演进的脉络。
诞生时间与历史定位不同
Hashtable 出现在 JDK 1.0（1996年），是 Java 最早的键值对容器之一，当时还没有 Map 接口；HashMap 则在 JDK 1.2（1998年）随集合框架（Collections Framework）一同推出，是为统一和现代化集合设计而生。
这意味着 Hashtable 是“前框架时代”的产物，而 HashMap 是框架体系下的标准实现——后者一出生就站在了更抽象、更一致的设计基础上。
继承体系反映设计理念差异
Hashtable 继承自已废弃的 Dictionary 抽象类，这个类早在 JDK 1.2 就被标记为 @Deprecated，官方注释明确指出“该类已过时，不应再使用”。它没融入集合框架的统一接口规范中。
立即学习“Java免费学习笔记（深入）”；
HashMap 则直接继承 AbstractMap，并完整实现 Map 接口，与 ArrayList、LinkedList 等同属一套设计语言：支持泛型、迭代器、标准化方法命名（如 containsKey() 而非 contains()）。
null 支持体现健壮性取舍
HashMap 允许一个 null 键 和任意多个 null 值，内部通过特殊逻辑（如 putForNullKey()）将 null 键固定存入数组索引 0 处，不依赖 hashCode 计算。
Hashtable 对 null 完全拒绝：只要 key 或 value 为 null，调用 put() 就抛 NullPointerException。这不是疏忽，而是早期设计中把 null 视为“非法输入”的保守策略——但这也让它的使用场景变窄，比如无法自然表达“未设置”或“默认值为空”这类语义。
线程安全机制暴露性能观变迁
Hashtable 所有 public 方法都加了 synchronized，是粗粒度的全表锁。这保证了线程安全，但也导致高并发下严重争用。
HashMap 默认不加锁，把同步责任交给使用者。这种“不安全但高效”的选择，恰恰为后来 ConcurrentHashMap 的出现铺平了道路——Java 5 引入的它，用分段锁（JDK 7）再到 CAS + synchronized（JDK 8+），实现了更细粒度、更高吞吐的并发控制。
换句话说：Hashtable 的同步是“时代局限”，HashMap 的非同步是“主动留白”，后者更符合现代并发编程的演进方向。
底层实现细节持续分化
两者都基于哈希表（数组 + 链表），但发展路径早已不同：
- HashMap 在 JDK 8 中引入红黑树优化：当链表长度 ≥ 8 且数组容量 ≥ 64 时，链表转为红黑树，最坏查找从 O(n) 降到 O(log n)；
- Hashtable 从未升级，始终维持数组 + 链表结构，也没有红黑树、扩容阈值等现代优化机制；
- HashMap 默认初始容量为 16（2 的幂），配合位运算快速计算索引；Hashtable 默认为 11（质数），扩容公式为
old * 2 + 1，更侧重旧式冲突分散策略。
这些区别不是偶然，而是 Java 从“能用”走向“好用”、“高性能”、“可维护”的缩影。今天几乎不再推荐使用 Hashtable，不是因为它错，而是因为它的设计目标已被更清晰、更强大、更符合工程实践的新组件所覆盖。
