Hashtable和HashMap区别及选择技巧

Hashtable虽线程安全但已废弃，因全局锁导致高并发下性能极差、API陈旧且不支持null；HashMap高效现代、适用单线程或手动同步场景，但直接用于多线程写入会引发数据不一致甚至死循环；真正面向高并发的首选是ConcurrentHashMap——它通过分段锁（JDK7）或CAS+细粒度同步（JDK8+）实现读操作无锁、写操作仅锁定局部桶，兼顾安全性与吞吐量，成为现代Java并发编程中哈希表的黄金标准。

Hashtable 是线程安全的，但基本不该用

Java 里 Hashtable 的所有 public 方法都加了 synchronized，确实线程安全，但代价是整个表被一把锁罩住——并发读写时严重串行化。JDK 1.5 后就明确不推荐使用，官方文档直接写 “This class is obsolete.”。它不支持 null 键或值，且继承自已废弃的 Dictionary 类，API 设计陈旧（比如 elements() 返回 Enumeration 而非 Iterator）。

除非你维护一段 JDK 1.2 时代的遗留代码，否则不要主动选 Hashtable。

HashMap 是默认选择，但必须自己处理线程安全

HashMap 非线程安全，单线程下性能好、API 现代、支持 null 键和值。多线程场景下若直接共享未同步的 HashMap，可能触发 ConcurrentModificationException，更危险的是在扩容时出现链表环（JDK 7）或数据丢失（JDK 8+），且无任何异常提示。

• 只读共享：多个线程只读，可用 Collections.unmodifiableMap(new HashMap())
• 简单同步：用 Collections.synchronizedMap(new HashMap())，但只是方法级同步，复合操作（如“检查后执行”）仍需手动加锁
• 高并发写：优先考虑 ConcurrentHashMap，分段锁（JDK 7）或 CAS + synchronized 优化（JDK 8+），支持更高吞吐

ConcurrentHashMap 才是现代多线程的正确答案

ConcurrentHashMap 不是 Hashtable 的升级版，而是从设计上重构的并发哈希表：默认 16 个分段桶（JDK 8 后改为基于 Node 数组 + CAS + 细粒度 synchronized），支持高并发读（无锁）、并发写（仅锁具体桶）、迭代时不阻塞写入。

注意几个关键差异：

• size() 不再是 O(1)，可能需遍历多个计数器，返回近似值；如需精确值，用 mappingCount()（返回 long）
• putIfAbsent()、computeIfAbsent() 等原子方法是核心优势，避免手写同步块
• 不支持 null 键或值（与 Hashtable 一致，但原因不同：为避免在并发中 null 带来的歧义）

性能差距在真实并发下才明显

单线程下 HashMap 比 ConcurrentHashMap 快约 10–20%，Hashtable 最慢（全局锁开销大）。但一旦有 4+ 线程频繁写入，Hashtable 吞吐会断崖下跌，ConcurrentHashMap 则基本保持线性增长。测试时容易忽略一点：用 System.nanoTime() 测微基准没问题，但若混合 GC、锁竞争、伪共享等，结果会失真。

真正该纠结的不是 “Hashtable vs HashMap”，而是 “是否真的需要并发写”——多数 Web 场景里，配置缓存、用户会话映射等，用 ConcurrentHashMap + 原子操作即可；而临时计算中间结果、方法内局部变量，HashMap 就够了。

文中关于的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《Hashtable和HashMap区别及选择技巧》文章吧，也可关注golang学习网公众号了解相关技术文章。