ConcurrentHashMap 1.7 vs 1.8：分段锁到 CAS+红黑树的演进与性能差异

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

ConcurrentHashMap 1.7 vs 1.8：分段锁到 CAS+红黑树的演进与性能差异

讲真，老程序员都得靠点岁月滤镜。我第一次深扒 ConcurrentHashMap 的源码，还是在 JDK 1.7 时代，那时候的哈希并发魂就是“分段锁”，每次和同事聊起，都有点“这玩意多神”的尬自豪。结果等到 1.8 出来，我突然尴尬地发现——这货都变天了！今天，就和大家唠唠我踩过的那些并发哈希坑。

老 ConcurrentHashMap 的分段锁江湖

Java 1.7 的 ConcurrentHashMap 纯粹是“分治思想”的现实写照。它把整个 Map 切成多个 Segment，每个 Segment 都是个小 HashTable，管自己一亩三分地。你 put、get、remove，基本不会打架：

• 分段锁（Segment）：每段一把锁，减少竞争
• 不支持 null key/null value（冷知识）

比如放数据，大致长这样：

int hash = hash(key);
int segmentIndex = (hash >>> segmentShift) & segmentMask;
Segment<K,V> s = segments[segmentIndex];
s.lock();
try {
    s.put(key, value);
} finally {
    s.unlock();
}

简化后的意思就是：我锁的只是 Segment，不像 HashTable 那样整个表锁死（所以 HashTable 几乎没人用了...）。

JDK 1.8：演变新世界，CAS+链表+红黑树

到了 1.8，这玩意彻底变了个腔调，“分段锁”拜拜，取而代之的是“桶级别”的操作＋一身并发黑科技：

• 不再有 Segment 数组，只有 Node[] table
• put 的时候，先 CAS 尝试抢占 Node（用 synchronized 兜底）
• 链表太长自动转红黑树，查找 O(logn) 不是梦

来，来，看核心放数据的套路：

Node<K,V>[] tab = table;
int i = (n - 1) & hash;
Node<K,V> f = tabAt(tab, i);
if (f == null) {
    if (casTabAt(tab, i, null, newNode)) {
        // CAS抢坑成功，无竞争~
    }
} else {
    synchronized (f) {
        // 操作链表或红黑树，争抢得激烈则自动变树！
    }
}

注：这 tabAt 跟 casTabAt 都是 Unsafe 的骚操作~

踩坑瞬间

我自己曾经经历过一次性能“大地震”。那会儿线上压测，两个不同 JDK 下 ConcurrentHashMap，居然结果天差地别。

痛点回忆：

• 1.7 多线程 put，性能稳定，但线程数过高还是得拼命锁各个段
• 1.8 急剧提升高并发下的写吞吐，尤其线程超多时，老版本直接锁段，等得人抓耳挠腮，新版 CAS 猛冲
• 红黑树救过命：有一回 keys 奇葩碰撞扎堆，1.7 直接挂了链表超长数秒。1.8 自动转树，时间稳定 O(logn)，查找都不带卡的

有次还诡异碰到过遍历 ConcurrentHashMap 一边 put 的场景，1.7 下因为 Segment 结构脑壳痛，1.8 基本溜了。

性能小对比

偷偷摸鱼做了下对比：

经验启示

• 多线程首选 1.8 及以上，不用 segment 锁省心
• Async 大量写入/高冲突 key，红黑树才是真香代码
• 不想卡链表查找？JDK 1.8 后不怕碰撞怪兽
• 想偷懒？1.8 遍历、并发用法更随心，不用操心锁分段

唉，老了，偶尔还是怀念 Segment 那点“老锁情怀”，但终究得向先进技术低头。也许代码本来也是进化史——每一版改动后，费神琢磨“为啥这样”，也就有了新技能傍身。大家有啥并发“笑话”，咱评论区扯一扯呗？

写到这儿，键盘都热了，今天就聊到这儿吧。忙到凌晨的程序员，才能继续踩下一个坑不是？