ConcurrentHashMap面试问题总结

Posted 2023-05-15

参考技术A Q:ConcurrentHashMap和HashMap的区别是什么？
A:
1.ConcurrentHashMap是线程安全的，HashMap是线程不安全的
2.ConcurrentHashMap不允许Key为null的值插入。而HashMap是可以的

Q:JDK8的ConcurrentHashMap和JDK7的ConcurrentHashMap有什么区别？
A:
1.JDK7的ConcurrentHashMap采用分段锁的策略，将整个数组分成多个segment，对这些segment进行分段加锁，使用的锁是ReentrantLock。而JDK8中的ConcurrentHashMap不采用分段锁的方式，直接使用Synchronized来进行。
2.JDK8中的ConcurrentHashMap新增了红黑树，并且插入用的是尾插法。
3.JDK7中的ConcurrentHashMap进行扩容时，是对当前的segment进行扩容，不会对其他segment有影响。而JDK8中就跟HashMap一样。整体扩容，但是保证线程安全

Q:JDK7中的ConcurrentHashMap是如何扩容的
A:JDK7中对每一段segment进行扩容，每一段segment的扩容跟HashMap保持一致

Q:JDK8中的ConcurrentHashMap是如何扩容的
A:在扩容时，首先会生成一个双倍大小的数组，生成完数组后，线程就会开始转移元素，在扩容的过程中，如果有其他线程在put，那么这个put线程会帮助去进行元素的转移，虽然叫转移，但是其实是基于原数组上的Node信息去生成一个新的Node的，也就是原数组上的Node不会消失，因为在扩容的过程中，如果有其他线程在get也是可以的。

Q:ConcurrentHashMap是如何保证线程安全的
A:
1.在JDK7的时候。ConcurrentHashMap是通过ReentrantLock+CAS+分段思想来保证的并发安全的，在JDK7的ConcurrentHashMap中，首先有一个Segment数组，存的是Segment对象，Segment相当于一个小HashMap，Segment内部有一个HashEntry的数组，也有扩容的阈值，同时Segment继承了ReentrantLock类，同时在Segment中还提供了put，get等方法，比如Segment的put方法在一开始就会去加锁，加到锁之后才会把key,value存到Segment中去，然后释放锁。同时在ConcurrentHashMap的put方法中，会通过CAS的方式把一个Segment对象存到Segment数组的某个位置中。同时因为一个Segment内部存在一个HashEntry数组，所以和HashMap对比来看，相当于分段了，每段里面是一个小的HashMap，每段公用一把锁，同时在ConcurrentHashMap的构造方法中是可以设置分段的数量的，叫做并发级别concurrencyLevel.
2.在JDK8的时候，ConcurrentHashMap是通过synchronized+cas来实现了。在JDK8中只有一个数组，就是Node数组，Node就是key，value，hashcode封装出来的对象，和HashMap中的Entry一样，在JDK8中通过对Node数组的某个index位置的元素进行同步，达到该index位置的并发安全。同时内部也利用了CAS对数组的某个位置进行并发安全的赋值。

面试之Hashtable和ConcurrentHashMap

那么要如何保证HashMap的线程安全呢？ 方法有很多，比如使用Hashtable或者Collections.synchronizedMap，但是这两位选手都有一个共同的问题：性能。因为不管是读还是写操作，他们都会给整个集合上锁，导致同一时间的其他操作被阻塞。

虽然Hashtable和Collections.synchronizedMap解决了HashMap的线程不安全的问题，但是带来了运行效率不佳的问题。

基于以上所述，兼顾了线程安全和运行效率的ConcurrentHashMap就出现了。

在了解了HashMap之后，接下来就开始了解一下ConcurrentHashMap。
ConcurrentHashMap与HashMap相比，最关键的是要理解一个概念：segment。
Segment其实就是一个Hashmap 。Segment也包含一个HashEntry数组，数组中的每一个HashEntry既是一个键值对，也是一个链表的头节点。
Segment对象在ConcurrentHashMap集合中有2的N次方个，共同保存在一个名为segments的数组当中。（类比HashMap来理解Segment就好）

因此ConcurrentHashMap的结构为：

换言之，ConcurrentHashMap是一个双层哈希表。在一个总的哈希表下面，有若干个子哈希表。（这样的双层结构，类似于数据库水平拆分来理解）

ConcurrentHashMap如此的设计，优势主要在于：
每个segment的读写是高度自治的，segment之间互不影响。这称之为“锁分段技术”；

看一下并发情况下的ConcurrentHashMap：
情景一：不同segment的并发写入

不同的Segment是可以并发执行put操作的

情景二：同一segment的并发写入

因为segment的写入是上锁的，因此对 同一segment的并发写入会被阻塞;

情景三：同一segment的一写一读

同一segment的写和读是可以并发执行的；

---

看到此处，就已经知道了ConcurrentHashMap的并发情况，有兴趣的话可以继续看下ConcurrentHashMap的具体读写过程。

Get方法：

1.为输入的Key做Hash运算，得到hash值。

2.通过hash值，定位到对应的Segment对象

3.再次通过hash值，定位到Segment当中数组的具体位置。

Put方法：

1.为输入的Key做Hash运算，得到hash值。

2.通过hash值，定位到对应的Segment对象

3.获取可重入锁

4.再次通过hash值，定位到Segment当中数组的具体位置。

5.插入或覆盖HashEntry对象。

6.释放锁。

---

看到此处，对于ConcurrentHashMap的Get和Put的过程（读写过程）就有了一个完整的了解了。
基于上述，会有一个问题：
每一个segment各自持有锁，那么在调用size()方法的时候（size()在实际开发大量使用），怎么保持一致性呢？
详细描述一下上面问题的情景：
Size方法的目的是统计ConcurrentHashMap的总元素数量， 肯定要把每个segment内部的元素数量都加起来。
那么假设一种情况，在统计segment元素数量的过程中，在统计结束前，已统计过的segment插入了新的元素，size()返回的数量就会出现不一致的问题。
为解决这个问题，ConcurrentHashMap的Size()方法是通过一个嵌套循环解决的，大体过程如下：
1.遍历所有的Segment。

2.把Segment的元素数量累加起来。

3.把Segment的修改次数累加起来。

4.判断所有Segment的总修改次数是否大于上一次的总修改次数。如果大于，说明统计过程中有修改，重新统计，尝试次数+1；如果不是。说明没有修改，统计结束。

5.如果尝试次数超过阈值，则对每一个Segment加锁，再重新统计。

6.再次判断所有Segment的总修改次数是否大于上一次的总修改次数。由于已经加锁，次数一定和上次相等。

7.释放锁，统计结束。

这种解决办法是不是似曾相识？没错，这种思想和乐观锁悲观锁的思想如出一辙（不熟悉乐观锁的道友可以看我转的一篇非常生动的介绍，传送门）

为了不锁所有segment，首先乐观地假设size过程中不会有修改。当尝试一定次数，才无奈转悲观，锁住所有segment以保证一致性。

补充：
1、以上都是基于Java1.7的ConcurrentHashMap原理和代码；

2、ConcurrentHashMap在对Key求Hash值的时候进行了两次Hash，目的是为了实现Segment均匀分布。

小结

---

说了那么多，针对Map子类的安全性可以总结如下几点：

• HashMap采用链地址法解决哈希冲突，多线程访问哈希表的位置并修改映射关系的时候，后执行的线程会覆盖先执行线程的修改，所以不是线程安全的
• Hashtable采用synchronized关键字解决了并发访问的安全性问题但是效率较低
• ConcurrentHashMap使用了线程锁分段技术，每次访问只允许一个线程修改哈希表的映射关系，所以是线程安全的