ConcurrentHashMap 的 get 要不要加锁？一次“多此一举”的心路历程

原文来自于：zha-ge.cn/java/37

ConcurrentHashMap 的 get 要不要加锁？一次“多此一举”的心路历程

搞 Java 的朋友，提起并发，哪个没和 Map 周旋过？我前阵子接了个项目，地图群魔乱舞，大家甩锅性能，一通群嘲都把目光怼到了 ConcurrentHashMap 上：有个人突然冒出个“get 其实也得加锁，不然不安全！”差点把我咖啡喷显示器上。行吧，这年头 Java 的黑魔法多，我就顺手扒一扒这坨事儿。

那天我为什么要想加锁

事情得从一次“有趣”的线上事故说起。某天我们线上业务偶有空指针，log 里指着 ConcurrentHashMap 的 get，键明明是 put 进去的呀。某位兄弟一拍脑袋：“可能是 get 也线程不安全吧，加个锁试试？”。 此言一出，气氛凝固了一秒——大家都用过单线程 HashMap 死锁的血泪教训，还真没好好想过 ConcurrentHashMap 的 get 是不是还能出妖风……于是我成了那个倒霉蛋，“你来扒下源码？”好嘞。

先说结论，ConcurrentHashMap 的 get，就是不用再套锁。 要/不要加锁的声音，不都基于“会不会读到脏数据”？但 get 怎么实现，真能跨线程出乱子吗？

源码刨根问底

我开了源码当夜宵。大致逻辑是：

• get 是无锁（不是完全 lock free，不过查 table[] 懂的都懂）
• get 查询，基本只读，不修改数据结构
• put、remove 才会相关段加锁（Segment 锁）
• 内部用 volatile 保证内存可见性，刚好防止“get 读到旧值”

来看个典型片段，get 方法蹭蹭两三行核心代码：

Node<K,V> e = tabAt(tab, i);
while (e != null) {
    if (e.hash == hash && (e.key == key || (key != null && key.equals(e.key))))
        return e.val;
    e = e.next;
}

你看，这不就是读 table 读链表吗，压根不加锁，你想 lock 也没地儿加。 重点：tabAt 用的是 Unsafe 的 volatile 级别读，保证多线程下读数据时一定是新的，不会给你乱来。

当时看到这，我心想：锁你个头啊锁！

踩坑瞬间

不过说真的，在我没细扒前，心里真有点毛。

• 看到线上偶发 null，我一度怀疑 get “撞枪口”读到 put/resize 的过程。
• 还好源码里，table[] 扩容、节点插入都通过 volatile 顺序和 synchronized/Segment 锁兜底，只有 put 关心并发修正，get 始终只需保证可见性——并不是所谓“脏读”。
• 再翻翻 JDK 8 的改动（从 Segment 分段到 CAS + volatile），发现设计就是读写分离，效率和安全都顾到了。

踩坑榜单：

• 【玄学】以为加锁能防止 “偶发 null”，其实根源是 put 过程或 get 时机出问题，锁甚至会徒增死锁风险。
• 【过度设计】非要给 get 包一层锁，连类库作者都要摇头。

经验启示

回头一看，主流并发容器的坑基本一摸一样，总结几条赛博血泪经验：

• ConcurrentHashMap 的 get，千万别再画蛇添足加锁，它天生为并发读优化；
• 真遇到奇怪的 null，先查 put 过程是不是异常/覆盖/并发问题，不要甩锅给 get；
• 记住 JDK 大佬们不是吃素的，遇到底层容器级别的“不是 bug 的 bug”，十有八九是自己代码逻辑飘了——不要先“修锅”，先修脑袋；
• 要锁，也是操作复合场景（put-if-absent+double check 这种），不是普通 get；
• 高并发基础设施，源码权威大于八卦文章，碰到疑点直接翻源码，比 YY 强多了。

写完这篇，喝口水冷静会，把 ConcurrentHashMap 的文档再温一遍。以后再有人说“要不要锁 get”，直接甩上面两行源码，不费话。

行了，头发又少两根，溜了溜了~