ConcurrentHashMap的介绍
ConcurrentHashMap的介绍
一、HashMap线程安全
我们知道,在并发情况下,使用HashMap会有线程安全的问题,那么如何避免呢?想要避免Hashmap的线程安全问题有很多办法,比如改用HashTable或者Collections.synchronizedMap
但是,这两者有着共同的问题:性能。无论读操作还是写操作,他们都会给整个集合加锁,导致同一时间的其他操作为之阻塞。
在并发环境下,如何能够兼顾线程安全和运行效率呢?这时候ConcurrentHashMap就应运而生来。
二、ConcurrentHashMap
ConcurrentHashMap 是由 Segment 数组结构和 HashEntry 数组结构组成。
在 JDK1.7 的时候,ConcurrentHashMap将数据分为一段一段(这个“段”就是 Segment
)的存储,然后给每一段数据配一把锁,当一个线程占用锁访问其中一个段数据时,其他段的数据也能被其他线程访问。因此,就不会存在锁竞争,提高并发访问率。
简单来说:ConcurrentHashMap优势就是采用了[锁分段技术],每一个Segment就好比自治区,读写操作高度自治,Segment之间互不影响。
java7 ConcurrentHashMap 存储结构:
1. Segment
这里面涉及到一个比较关键的概念:Segment。
Segment本身就相当于一个HashMap对象。同HashMap一样,Segment 包含一个HashEntry数组,数组中的每一个HashEntry既是一个键值对,也是一个链表的头节点。
单一的Segment结构如下:
Segment
继承了 ReentrantLock,
所以 Segment
是一种可重入锁,扮演锁的角色。HashEntry
用于存储键值对数据。
1 static class Segment<K,V> extends ReentrantLock implements Serializable { 2 //... 3 }
说明:一个 ConcurrentHashMap 里包含一个 Segment 数组,Segment 的个数一旦初始化就不能改变。 Segment 数组的大小默认是 16,也就是说默认可以同时支持 16 个线程并发写。
像这样的 Segment
对象,在ConcurrentHashMap集合中有2的N次方个,共同保存在一个名为segments的数组当中。
因此整个ConcurrentHashMap的结构如下:
可以说,ConcurrentHashMap是一个二级哈希表。在一个总的哈希表下面,有若干个子哈希表。
这样的二级结构,和数据库的水平拆分有些相似。
2. ConcurrentHashMap并发读写的几种情形
Segment 的结构和 HashMap 类似,是一种数组和链表结构,一个 Segment 包含一个 HashEntry 数组,每个 HashEntry 是一个链表结构的元素,每个 Segment 守护着一个 HashEntry 数组里的元素,当对 HashEntry 数组的数据进行修改时,必须首先获得对应的 Segment 的锁。也就是说,对同一 Segment 的并发写入会被阻塞,不同 Segment 的写入是可以并发执行的。
1)Case1: 不同Segment的并发写入
说明:不同Segment的写入是可以并发执行的。
2)Case2: 同一Segment的一写一读
说明:同一Segment的写和读是可以并发执行的。
3)Case3:同一Segment的并发写入
说明:Segment的写入是需要上锁的,因此对同一Segment的并发写入会被阻塞。
由此可见,ConcurrentHashMap当中每个Segment各自持有一把锁。在保证线程安全的同时降低了锁的粒度,让并发操作效率更高。
3. ConcurrentHashMap读写的详细过程
1)get() 方法
- 为输入的Key做Hash运算,得到hash值。
- 通过hash值,定位到对应的Segment对象
- 再次通过hash值,定位到Segment当中数组的具体位置。
2)put() 方法
- 为输入的Key做Hash运算,得到hash值。
- 通过hash值,定位到对应的Segment对象
- 获取可重入锁
- 再次通过hash值,定位到Segment当中数组的具体位置。
- 插入或覆盖HashEntry对象。
说明:从步骤可以看出,ConcurrentHashMap在读写时都需要二次定位。首先定位到Segment,之后定位到Segment内的具体数组下标。
4. 调用size方法时,如何解决一致性问题?
1)分析
这个问题Key理解为:既然每一个Segment都各自加锁,那么在调用Size方法的时候,怎么解决一致性的问题呢?
Size方法的目的是统计ConcurrentHashMap的总元素数量, 自然需要把各个Segment内部的元素数量汇总起来。
但是,如果在统计Segment元素数量的过程中,已统计过的Segment瞬间插入新的元素,这时候该怎么办呢?如下图:
ConcurrentHashMap的Size方法是一个嵌套循环,大体逻辑如下:
- 遍历所有的Segment。
- 把Segment的元素数量累加起来。
- 把Segment的修改次数累加起来。
- 判断所有Segment的总修改次数是否大于上一次的总修改次数。如果大于,说明统计过程中有修改,重新统计,尝试次数+1;如果不是。说明没有修改,统计结束。
- 如果尝试次数超过阈值,则对每一个Segment加锁,再重新统计。
- 再次判断所有Segment的总修改次数是否大于上一次的总修改次数。由于已经加锁,次数一定和上次相等。
- 释放锁,统计结束。
官方源代码如下:
1 public int size() { 2 // Try a few times to get accurate count. On failure due to 3 // continuous async changes in table, resort to locking. 4 final Segment<K,V>[] segments = this.segments; 5 int size; 6 boolean overflow; // true if size overflows 32 bits 7 long sum; // sum of modCounts 8 long last = 0L; // previous sum 9 int retries = -1; // first iteration isn't retry 10 try { 11 for (;;) { 12 if (retries++ == RETRIES_BEFORE_LOCK) { 13 for (int j = 0; j < segments.length; ++j) 14 ensureSegment(j).lock(); // force creation 15 } 16 sum = 0L; 17 size = 0; 18 overflow = false; 19 for (int j = 0; j < segments.length; ++j) { 20 Segment<K,V> seg = segmentAt(segments, j); 21 if (seg != null) { 22 sum += seg.modCount; 23 int c = seg.count; 24 if (c < 0 || (size += c) < 0) 25 overflow = true; 26 } 27 } 28 if (sum == last) 29 break; 30 last = sum; 31 } 32 } finally { 33 if (retries > RETRIES_BEFORE_LOCK) { 34 for (int j = 0; j < segments.length; ++j) 35 segmentAt(segments, j).unlock(); 36 } 37 } 38 return overflow ? Integer.MAX_VALUE : size; 39 }
2)为什么这样设计呢?
这种思想和乐观锁悲观锁的思想如出一辙。
原因:为了尽量不锁住所有Segment,首先乐观地假设Size过程中不会有修改。当尝试一定次数,才无奈转为悲观锁,锁住所有Segment保证强一致性。
三、注意事项
1. 这里介绍的ConcurrentHashMap原理和代码,都是基于Java1.7的。在Java8中会有些许差别。
Java8 ConcurrentHashMap存储结构:
Java 8 几乎完全重写了 ConcurrentHashMap,代码量从原来 Java 7 中的 1000 多行,变成了现在的 6000 多行。
ConcurrentHashMap 取消了 Segment 分段锁,采用 Node数组 + CAS + synchronized 来保证并发安全。数据结构跟 HashMap 1.8 的结构类似,数组+链表/红黑二叉树。Java 8 在链表长度超过一定阈值(8)时将链表(寻址时间复杂度为 O(N))转换为红黑树(寻址时间复杂度为 O(log(N)))
Java 8 中,锁粒度更细,synchronized 只锁定当前链表的头节点或红黑二叉树的根节点,这样只要 hash 不冲突,就不会产生并发,就不会影响其他 Node 的读写,效率大幅提升。
虽然在 JDK1.8 中还能看到 Segment 的数据结构,但是已经简化了属性,只是为了兼容旧版本。
源码如下:
1 /** 2 * Stripped-down version of helper class used in previous version, 3 * declared for the sake of serialization compatibility 4 */ 5 static class Segment<K,V> extends ReentrantLock implements Serializable { 6 private static final long serialVersionUID = 2249069246763182397L; 7 final float loadFactor; 8 Segment(float lf) { this.loadFactor = lf; } 9 }
2. 两次Hash
ConcurrentHashMap在对Key求Hash值的时候,为了实现 Segment 均匀分布,进行了两次Hash
具体来说:为了实现Segment的均匀分布,采用了两次Hash的策略。首先,它使用了传统的Hash算法(比如将Key的hashCode取模),得到的结果称为哈希值。然后,它对这个哈希值再进行一次Hash操作,这个操作通常称为“再散列”(rehashing),目的是进一步增加哈希值的随机性,减少哈希碰撞的概率,从而提高并发性能。这样得到的最终哈希值用于确定Key在哪个Segment中的位置。
参考资料:
《程序员小灰》微信公众号
https://javaguide.cn/