Java并发容器：ConcurrentHashMap与Hashtable锁粒度对比

本文深入剖析了Java并发容器中ConcurrentHashMap与Hashtable在锁机制上的本质差异：ConcurrentHashMap通过分段锁（1.7）或CAS+synchronized单节点锁（1.8+）实现极致细粒度控制，读操作无锁、写操作仅锁定冲突桶，支持高并发读写；而Hashtable采用粗粒度的全局对象锁，导致任意读写操作都会相互阻塞，性能瓶颈明显。文章不仅厘清了常见误区（如“ConcurrentHashMap完全无锁”“size()绝对准确”），还结合典型业务场景（缓存、计数、遍历）给出选型建议，并警示开发者真正危险的不是容器选择本身，而是对线程安全行为的错误假设——这些隐含强一致性要求的地方，往往成为难以复现的竞态问题根源。

ConcurrentHashMap 的分段锁和 CAS 是怎么工作的

ConcurrentHashMap 不是靠整个 Map 加锁来保证线程安全的，它把数据分成多个 Segment（1.7）或用 Node 数组 + volatile + CAS（1.8+），锁只落在具体桶（bucket）上。这意味着读操作几乎无锁，写操作也只锁住冲突的那一小片区域。

常见错误是以为 ConcurrentHashMap 对所有操作都“完全无锁”——其实 putIfAbsent、computeIfAbsent 这类复合操作仍需加锁或重试，尤其在高并发下可能因 CAS 失败而自旋多次。

• 1.7 版本：默认 16 个 Segment，锁粒度 ≈ 数组长度 / 16；可通过构造参数 concurrencyLevel 调整，但只是估算值，不是硬限制
• 1.8+ 版本：去掉 Segment，改用 synchronized 锁单个 Node 链表头或红黑树根，配合 Unsafe.compareAndSwapObject 做初始化和扩容控制
• 扩容时采用“多线程协助扩容”机制：第一个触发扩容的线程建新表，后续线程若发现正在扩容，会主动帮着迁移部分桶，而不是排队等待

Hashtable 为什么一写就卡住所有读

Hashtable 所有 public 方法都用 synchronized 修饰，等价于对整个对象加锁。哪怕你只 put 一个 key，其他线程想 get 任意 key 都得等——锁粒度是整个实例，不是某个桶，也不是某个 key。

典型误用场景：用 Hashtable 存配置项，但频繁调用 get，结果发现 QPS 上不去，CPU 却不高，其实是大量线程在锁池里阻塞等待。

• containsKey 和 get 都要抢同一把锁，无法并发读
• 迭代器 Enumeration 是 fail-fast 的，且遍历时锁住整个表，期间任何写操作都会被阻塞
• 不支持 null key 或 value，抛 NullPointerException，这点和 ConcurrentHashMap 一致，但错误时机不同：前者在 put 时就报，后者允许 null value（JDK 1.8+）

什么时候该选 ConcurrentHashMap 而不是 Hashtable

除非你在维护一段 JDK 1.4 的老代码，否则没有理由选 Hashtable。它的设计目标是“线程安全”，但实现方式早已过时，性能差、扩展性弱、API 陈旧。

真实项目中，选 ConcurrentHashMap 的核心依据是：读多写少 + 需要高吞吐 + 不能接受全局阻塞。

• Web 应用缓存用户 session ID → 用 ConcurrentHashMap，因为 get 极频繁，put 较少且分散
• 统计接口调用量（按 path 分桶计数）→ 用 ConcurrentHashMap，每个 path 的计数互不干扰
• 需要强一致性遍历（比如 dump 全量状态）→ ConcurrentHashMap 的 entrySet().iterator() 不保证反映某一时刻快照，此时得自己加外部锁或用 CopyOnWriteArrayList 配合

ConcurrentHashMap 的 size() 和 isEmpty() 为什么不准

size() 在 1.8+ 中返回的是一个估算值：它累加每个 bin 的 baseCount，再结合 counterCells 数组的增量，但不加锁也不阻塞。所以并发修改时，可能漏计或重复计数。

这不是 bug，是设计取舍——为了不牺牲并发性能，放弃绝对精确的大小统计。

• isEmpty() 同样是估算：只检查 baseCount == 0 且所有 bin 都为空，但中间可能有线程刚插入又还没更新计数
• 如果业务逻辑依赖“是否为空”做分支（比如空则初始化），别直接用 isEmpty()，应改用 computeIfAbsent 或先 get 再判断
• size() 在扩容过程中可能短暂翻倍或归零，日志里看到 “size=2000, then size=0, then size=4000” 属正常现象

真正难处理的从来不是“怎么选容器”，而是当你的业务逻辑隐含了对容器行为的强假设（比如认为 size() 可靠、或 put 后立刻能被所有线程 get 到），这些地方最容易出竞态问题，而且很难复现。

本篇关于《Java并发容器：ConcurrentHashMap与Hashtable锁粒度对比》的介绍就到此结束啦，但是学无止境，想要了解学习更多关于文章的相关知识，请关注golang学习网公众号！