什么是ConcurrentHashMap？（jdk1.8以下版本）

最新推荐文章于 2024-08-23 00:00:00 发布

csdn_586

最新推荐文章于 2024-08-23 00:00:00 发布

阅读量980

点赞数 1

分类专栏：数据结构

数据结构专栏收录该内容

6 篇文章 0 订阅

订阅专栏

想要避免HashMap的线程安全问题有很多办法，比如改用HashTable或者Collection.synchronizedMap。但是这两者有着共同的问题：性能。无论是读操作还是写操作，它们都会给整个集合加锁，导致同一时间的其他操作为之阻塞。

在并发环境下，如何能够兼顾线程安全和运行效率呢？这时候，ConcurrentHashMap就应运而生了。

掌握HashMap后，学习ConcurrentHashMap其实很简单，最关键是要理解一个概念：Segment。

---------------------------------------------------------------------------------------------------------------------------------------

Segment是什么呢？Segment本身就相当于一个HashMap对象。同HashMap一样，Segment包含一个HashEntry数组，数组中的每一个HashEntry既是一个键值对，也是一个链表的头节点。

像这样的Segment对象，在ConcurrentHashMap集合中有多少个呢？2的N次方个，共同保存在一个名为Segments的数组中。

可以说，ConcurrentHashMap是一个二级哈希表，在一个总的哈希表下面有若干个子哈希表。

Segment

我们再来具体了解一下Segment的数据结构：

    Java代码   
    
  
static final class Segment<K,V> extends ReentrantLock implements Serializable {  
    transient volatile int count;  
    transient int modCount;  
    transient int threshold;  
    transient volatile HashEntry<K,V>[] table;  
    final float loadFactor;  
}  

详细解释一下Segment里面的成员变量的意义：

count：Segment中元素的数量
modCount：对table的大小造成影响的操作的数量（比如put或者remove操作）
threshold：阈值，Segment里面元素的数量超过这个值依旧就会对Segment进行扩容
table：链表数组，数组中的每一个元素代表了一个链表的头部
loadFactor：负载因子，用于确定threshold

HashEntry

Segment中的元素是以HashEntry的形式存放在链表数组中的，看一下HashEntry的结构：

    Java代码   
    
  
static final class HashEntry<K,V> {  
    final K key;  
    final int hash;  
    volatile V value;  
    final HashEntry<K,V> next;  
}  

可以看到HashEntry的一个特点，除了value以外，其他的几个变量都是final的，这样做是为了防止链表结构被破坏，出现ConcurrentModification的情况。

---------------------------------------------------------------------------------------------------------------------------------------

ConcurrentHashMap这样设计有什么好处呢？

ConcurrentHashMap优势就是采用了【锁分段技术】，每一个Segment就好比一个自治区，读写操作高度自治，Segment之间互不影响。

Case1：不同Segment 的并发写入

这里写图片描述

不同Segment的写入是可以并发执行的。

Case2：同一Segment的一写一读

这里写图片描述

同一Segment的写和读是可以并发执行的。

Case3：同一Segment的并发写入

这里写图片描述

Segment的写入是需要上锁的，因此对同一Segment的并发写入会被阻塞。

由此可见，ConcurrentHashMap当中每个Segment各自持有一把锁。在保证线程安全的同时降低了锁的粒度，让并发操作效率更高。

---------------------------------------------------------------------------------------------------------------------------------------

Concurrent 的读写过程

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.释放锁。

读写操作均需要二次定位到Segment

---------------------------------------------------------------------------------------------------------------------------------------

ConcurrentHashMap 在调用Size 方法时如何解决一致性问题？

Size方法的目的是统计ConcurrentHashMap的总元素数量，自然需要把各个Segment内部的元素数量汇总起来。

但是，如果在统计Segment元素数量的过程中，已统计过的Segment瞬间插入新的元素，这时候该怎么办呢？

ConcurrentHashMap的Size方法是一个嵌套循环，大体逻辑如下：

1.遍历所有的Segment。

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

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

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

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

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

7.释放锁，统计结束。

public int size() {
   // Try a few times to get accurate count. On failure due to
   // continuous async changes in table, resort to locking.
   final Segment<K,V>[] segments = this.segments;
    int size;
    boolean overflow; // true if size overflows 32 bits
    long sum;         // sum of modCounts
    long last = 0L;   // previous sum
    int retries = -1; // first iteration isn't retry
    try {
        for (;;) {
            if (retries++ == RETRIES_BEFORE_LOCK) {
                for (int j = 0; j < segments.length; ++j)
                    ensureSegment(j).lock(); // force creation
            }
            sum = 0L;
            size = 0;
            overflow = false;
            for (int j = 0; j < segments.length; ++j) {
                Segment<K,V> seg = segmentAt(segments, j);
                if (seg != null) {
                    sum += seg.modCount;
                    int c = seg.count;
                    if (c < 0 || (size += c) < 0)
                        overflow = true;
                }
            }
            if (sum == last)
                break;
            last = sum;
        }
    } finally {
        if (retries > RETRIES_BEFORE_LOCK) {
            for (int j = 0; j < segments.length; ++j)
                segmentAt(segments, j).unlock();
        }
    }
    return overflow ? Integer.MAX_VALUE : size;
}

为什么这样设计呢？这种思想和乐观锁悲观锁的思想如出一辙。

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

参考：https://my.oschina.net/hosee/blog/675884