面试官：为什么ConcurrentHashMap要放弃分段锁？

今天我们来讨论一下一个比较经典的面试题就是 ConcurrentHashMap 为什么放弃使用了分段锁，这个面试题阿粉相信很多人肯定觉得有点头疼，因为很少有人在开发中去研究这块的内容，今天阿粉就来给大家讲一下这个 ConcurrentHashMap 为什么在 JDK8 中放弃了使用分段锁。

什么是分段锁

我们都知道 HashMap 是一个线程不安全的类，多线程环境下，使用 HashMap 进行put操作会引起死循环，导致CPU利用率接近100%，所以如果你的并发量很高的话，所以是不推荐使用 HashMap 的。

而我们所知的，HashTable 是线程安全的，但是因为 HashTable 内部使用的 synchronized 来保证线程的安全，所以，在多线程情况下，HashTable 虽然线程安全，但是他的效率也同样的比较低下。

所以就出现了一个效率相对来说比 HashTable 高，但是还比 HashMap 安全的类，那就是 ConcurrentHashMap，而 ConcurrentHashMap 在 JDK8 中却放弃了使用分段锁，为什么呢？那他之后是使用什么来保证线程安全呢？我们今天来看看。

什么是分段锁？

其实这个分段锁很容易理解，既然其他的锁都是锁全部，那分段锁是不是和其他的不太一样，是的，他就相当于把一个方法切割成了很多块，在单独的一块上锁的时候，其他的部分是不会上锁的，也就是说，这一段被锁住，并不影响其他模块的运行，分段锁如果这样理解是不是就好理解了，我们先来看看 JDK7 中的 ConcurrentHashMap 的分段锁的实现。

在 JDK7 中 ConcurrentHashMap 底层数据结构是数组加链表，这也是之前阿粉说过的 JDK7和 JDK8 中 HashMap 不同的地方，源码送上。

//初始总容量，默认16
static final int DEFAULT_INITIAL_CAPACITY = 16;
//加载因子，默认0.75
static final float DEFAULT_LOAD_FACTOR = 0.75f;
//并发级别，默认16
static final int DEFAULT_CONCURRENCY_LEVEL = 16;

static final class Segment<K,V> extends ReentrantLock implements Serializable {

transient volatile HashEntry<K,V>[] table;

}

在阿粉贴上的上面的源码中，有Segment<K,V>,这个类才是真正的的主要内容， ConcurrentHashMap 是由 Segment 数组结构和 HashEntry 数组结构组成.

我们看到了 Segment<K,V>,而他的内部，又有HashEntry数组结构组成. Segment 继承自 RentrantLock 在这里充当的是一个锁，而在其内部的