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

分手后的思念是犯贱 2023-09-28 22:00 69阅读 0赞

今天我们来讨论一下一个比较经典的面试题就是 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` 在这里充当的是一个锁，而在其内部的