ConcurrentHashMap是如何保证线程安全的

妖狐艹你老母 2024-03-23 17:14 77阅读 0赞

#### ConcurrentHashMap是如何保证线程安全的 ####

*  1. 定义和作用
 *  2. JDK1.7中保证线程安全的原理
 *   *  2.1 数据结构
     *  2.2 基于分段锁实现
     *  2.3 ReentrantLock重入锁
     *   *  2.3.1 定义
         *  2.3.2 特点
 *  3. JDK1.8中性能优化原理
 *   *  3.1 数据结构上的变化
     *  3.2 源码实现
     *  3.3 总结
 *  4. 概括
 *   *  JDK1.7
     *  JDK1.8

## 1. 定义和作用 ##

ConcurrentHashMap相当于HashMap的**多线程版本**。

它的功能本质上和HashMap没有什么区别，但HashMap在并发操作的时候会出现各种问题，比如死循环、数据覆盖等问题。

而这些问题只要使用ConcurrentHashMap就能得到完美的解决。

## 2. JDK1.7中保证线程安全的原理 ##

![在这里插入图片描述][72caf17b8773485f99de487c93b1fe98.png]

### 2.1 数据结构 ###

JDK 1.7中ConcurrentHashMap的底层结构基本延续了HashMap的基本设计。它采用的是**数组加链表**的形式。

和HashMap不同的是ConcurrentHashMap中的数组被封分为**大数组和小数组**。

**大数组是Segment，小数组是HashEntry**。

大数组Segment可以理解为是一个**数据库**，而这个数据库又有很多张表，这个**表**就是HashEntry。

每个HashEntry中又有很多条**数据**，这些数据采用的是**链表结构**。

### 2.2 基于分段锁实现 ###

因为Segment本身是基于**ReentrantLock重入锁**的实现来加锁和释放锁的操作。

这样的话就能够保证多线程同时访问ConcurrentHashMap的时候，同一时间只能有一个线程操作对应的节点，进而保证了ConcurrentHashMap的线程安全。

也就是说ConcurrentHashMap的线程安全是建立在**Segment的加锁**的基础上，所以我们称它为**分段锁**或者是**分片锁**。

### 2.3 ReentrantLock重入锁 ###

#### 2.3.1 定义 ####

ReentrantLock（重入锁）是Java中提供的一种同步机制，用于实现多线程之间的互斥访问。

它是一种**独占锁**，也就是说，在任何时候只能有一个线程持有该锁，并且其他线程必须等待锁的释放才能获取它。

#### 2.3.2 特点 ####

与synchronized关键字相比，ReentrantLock提供了很多的灵活性和功能。

它是可重入的，意味着**同一个线程可以多次获得同一把锁**，而不会导致死锁。当一个线程多次获取锁时，它必须相应地释放相同次数的锁，才能使其他等待的线程获得该锁。

ReentrantLock还提供了**公平性选择**，可以选择是否按照线程请求锁的顺序来获取锁。默认情况下，它是非公平的，允许通过竞争来提高吞吐量。而公平锁将按照线程的请求顺序来获取锁，保证了每个线程都有公平的机会获得锁，但可能会降低吞吐量。

使用ReentrantLock**需要手动获取锁和释放锁**。

在使用ReentrantLock时，**必须确保在获取锁后正确释放锁**，否则可能会导致死锁或其他并发问题。因此，通常使用`try-finally`块来确保锁的释放操作在任何情况下都会执行。

总的来说，ReentrantLock是一种可重入的、灵活而强大的同步机制，可以用于实现更复杂的多线程同步需求。

## 3. JDK1.8中性能优化原理 ##

### 3.1 数据结构上的变化 ###

在JDK1.7中，ConcurrentHashMap虽然是线程安全的，但是它的底层实现是采用**数组+链表**的形式。所以在数据比较多的情况下，因为要**遍历**整个链表，这样的话会降低它的访问性能。

JDK1.8以后，就采用了**数组+链表+红黑树**的方式进行的优化。  
![在这里插入图片描述][f5d78bb830144ba489aefe9995c93e27.png]  
当我们的**链表长度大于8**的时候，**并且数组长度大于64**的时候，链表就会升级为红黑树的结构。

JDK1.8中，ConcurrentHashMap保留了Segment的定义，但是仅仅是为了保证序列化的时候的兼容性，**不再有任何结构上的用途**了。

### 3.2 源码实现 ###

那在JDK1.8中，ConcurrentHashMap的源码又是如何实现的呢？

它主要是通过**CAS+volatile**或者是**synchronized**的方法来实现的，保证线程安全。

**首先会判断容器是否为空**：

1.  如果**容器为空**，就会使用**volatile+CAS来初始化**。
2.  如果**容器不为空**，就会根据存储的元素**计算该位置是否为空**。  
    1）如果根据存储元素的计算结果**为空**，就会利用**CAS**来设计该节点。  
    2）如果根据存储元素的计算结果**不为空**，就会使用**synchronized加锁**来进行实现。然后去遍历桶中的数据，并且替换或新增节点到桶中。最后判断是否有必要转为红黑树。这样就保证了并发访问的线程安全。

![在这里插入图片描述][dd09f98c156d4a5e952e29ecae68f2c0.png]

### 3.3 总结 ###

如果把上面的执行用一句话来归纳的话，就相当于ConcurrentHashMap通过对**头节点加锁**来保证线程安全，这样设计的好处是使得**锁的粒度**相比Segment来说更小了，发生**hash冲突和加锁的频率**也更低了，而在并发场景下操作**性能**也提高了。而且当数据量比较大的时候，查询性能也得到了进一步的提升。

## 4. 概括 ##

### JDK1.7 ###

使用**数组+链表**，其中数组分为两大类，**大数组**是Segment，**小数组**是HashEntry。而加锁是通过**Segment添加ReentrantLock重入锁**来保证线程安全的。

### JDK1.8 ###

使用**数组+链表+红黑树**，它是通过**CAS或者synchronized**来实现线程安全。并且也缩小了锁的粒度，查询性能也到了进一步的提升。

**参考资料**：[【Java面试】京东二面，ConcurrentHashMap是如何保证线程安全？][Java_ConcurrentHashMap]

[72caf17b8773485f99de487c93b1fe98.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/23/2a8c3e397fe944c58ce251d79f5d59df.png
[f5d78bb830144ba489aefe9995c93e27.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/23/fd4b5029c69a4aa78893aae935e7e528.png
[dd09f98c156d4a5e952e29ecae68f2c0.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/23/535b0ac2d7214d95b31de13f2a73e177.png
[Java_ConcurrentHashMap]: https://www.bilibili.com/video/BV1xj411c7d4/?spm_id_from=333.337.search-card.all.click&vd_source=a1af903e57688df870625021f7f3a7eb