Hashtable 已废弃，因全局锁导致并发性能差且API陈旧；HashMap 非线程安全但高效现代；多线程写应优先用 ConcurrentHashMap，其分段锁/CAS 机制保障高并发安全与性能。
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），支持高并发读（无锁）、并发写（仅锁具体桶）、迭代时不阻塞写入。
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
立即学习“Java免费学习笔记（深入）”；
注意几个关键差异：
-
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 就够了。
