Java8开始ConcurrentHashMap,为什么舍弃分段锁?

概述

我们知道， 在 Java 5 之后，JDK 引入了 java.util.concurrent 并发包 ，其中最常用的就是
ConcurrentHashMap 了， 它的原理是引用了内部的 Segment ( ReentrantLock )
分段锁，保证在操作不同段 map 的时候， 可以并发执行， 操作同段 map 的时候，进行锁的竞争和等待。从而达到线程安全， 且效率大于synchronized。但是在 Java 8 之后， JDK 却弃用了这个策略，重新使用了 synchronized+cas。

弃用原因

通过 JDK 的源码和官方文档看来， 他们认为的弃用分段锁的原因由以下几点：

1: 加入多个分段锁浪费内存空间。
2: 生产环境中， map 在放入时竞争同一个锁的概率非常小，分段锁反而会造成更新等操作的长时间等待。
3:为了提高GC 的效率

新的同步方案

既然弃用了分段锁， 那么一定由新的线程安全方案，

我们来看看源码是怎么解决线程安全的呢？（源码保留了segment 代码， 但并没有使用）

put

首先通过 hash 找到对应链表过后， 查看是否是第一个object， 如果是， 直接用cas原则插入，无需加锁。

Node<K,V> f; int n, i, fh; K fk; V fv;
if (tab == null || (n = tab.length) == 0)
    tab = initTable(); // 这里在整个map第一次操作时，初始化hash桶， 也就是一个table
else if ((f = tabAt(tab, i =