ConcurrentHashMap实现原理及源码分析

最新推荐文章于 2024-04-07 16:29:10 发布

七月J

最新推荐文章于 2024-04-07 16:29:10 发布

阅读量236

点赞数

分类专栏： Java 文章标签： java.util.concurrent concurrent hashmap

原文链接：https://www.jianshu.com/p/865c813f2726

版权

Java 专栏收录该内容

22 篇文章 6 订阅

订阅专栏

ConcurrentHashMap是Java并发包中提供的一个线程安全且高效的HashMap实现（若对HashMap的实现原理还不甚了解，可参考我的另一篇文章 HashMap实现原理及源码分析），ConcurrentHashMap在并发编程的场景中使用频率非常之高，本文就来分析下ConcurrentHashMap的实现原理，并对其实现原理进行分析。

ConcurrentHashMap实现原理

众所周知，哈希表是中非常高效，复杂度为O(1)的数据结构，在Java开发中，我们最常见到最频繁使用的就是HashMap和HashTable，但是在线程竞争激烈的并发场景中使用都不够合理。

HashMap ：HashMap是线程不安全的，在并发环境下，可能会形成环状链表（扩容时可能造成，具体原因自行百度google或查看源码分析），导致get操作时，cpu空转，所以，在并发环境中使用HashMap是非常危险的。

HashTable ： HashTable和HashMap的实现原理几乎一样，差别无非是：1.HashTable不允许key和value为null；2. HashTable是线程安全的。但是HashTable线程安全的策略实现代价却太大了，简单粗暴，get/put所有相关操作都是synchronized的，这相当于给整个哈希表加了一把大锁，多线程访问时候，只要有一个线程访问或操作该对象，那其他线程只能阻塞，相当于将所有的操作串行化，在竞争激烈的并发场景中性能就会非常差。

在这里插入图片描述
HashTable性能差主要是由于所有操作需要竞争同一把锁，而如果容器中有多把锁，每一把锁锁一段数据，这样在多线程访问时不同段的数据时，就不会存在锁竞争了，这样便可以有效地提高并发效率。这就是ConcurrentHashMap所采用的"分段锁"思想。

在这里插入图片描述

ConcurrentHashMap源码分析

在 1.7 的实现

jdk1.7中采用 Segment + HashEntry 的方式进行实现，结构如下：

在这里插入图片描述

ConcurrentHashMap采用了非常精妙的 “分段锁” 策略，ConcurrentHashMap的主干是个Segment数组。

final Segment<K,V>[] segments;

Segment 是 ConcurrentHashMap 的一个内部类，主要的组成如下：

static final class Segment<K,V> extends ReentrantLock implements Serializable {

    private static final long serialVersionUID = 2249069246763182397L;

    // 和 HashMap 中的 HashEntry 作用一样，真正存放数据的桶
    transient volatile HashEntry<K,V>[] table;

    transient int count;

    transient int modCount;

    transient int threshold;

    final float loadFactor;
}

看看其中 HashEntry 的组成：一个ConcurrentHashMap维护一个Segment数组，一个Segment维护一个HashEntry数组。
在这里插入图片描述
和 HashMap 非常类似，唯一的区别就是其中的核心数据如 value ，以及链表都是 volatile 修饰的，保证了获取时的可见性。

原理上来说：Segment继承了ReentrantLock，所以它就是一种可重入锁（ReentrantLock)。在ConcurrentHashMap，一个Segment就是一个子哈希表，Segment 里维护了一个HashEntry数组，并发环境下，对于不同Segment的数据进行操作是不用考虑锁竞争的。（就按默认的ConcurrentLeve为16，理论上就允许16个线程并发执行）

所以，对于同一个Segment的操作才需考虑线程同步，不同的Segment则无需考虑。

我们说Segment类似哈希表，那么一些属性就跟我们之前提到的HashMap差不离，比如负载因子loadFactor，比如阈值threshold等等，看下Segment的构造方法

Segment(float lf, int threshold, HashEntry<K,V>[] tab) {
	 this.loadFactor = lf;//负载因子
     this.threshold = threshold;//阈值
     this.table = tab;//主干数组即HashEntry数组
}

我们来看下ConcurrentHashMap的构造方法

public ConcurrentHashMap(int initialCapacity, float loadFactor, int concurrencyLevel) {
	if (!(loadFactor > 0) || initialCapacity < 0 || concurrencyLevel <= 0)
	     throw new IllegalArgumentException();
	 //MAX_SEGMENTS 为1<<16=65536，也就是最大并发数为65536
	 if (concurrencyLevel > MAX_SEGMENTS)
	     concurrencyLevel = MAX_SEGMENTS;
	 //2的sshif次方等于ssize，例:ssize=16,sshift=4;ssize=32,sshif=5
	int sshift = 0;
	//ssize 为segments数组长度，根据concurrentLevel计算得出
	int ssize = 1;
	while (ssize < concurrencyLevel) {
	    ++sshift;
	    ssize <<= 1;
	}
	//segmentShift和segmentMask这两个变量在定位segment时会用到，后面会详细讲
	this.segmentShift = 32 - sshift;
	this.segmentMask = ssize - 1;
	if (initialCapacity > MAXIMUM_CAPACITY)
	    initialCapacity = MAXIMUM_CAPACITY;
	//计算cap的大小，即Segment中HashEntry的数组长度，cap也一定为2的n次方.
	int c = initialCapacity / ssize;
	if (c * ssize < initialCapacity)
	    ++c;
	int cap = MIN_SEGMENT_TABLE_CAPACITY;
	while (cap < c)
	    cap <<= 1;
	//创建segments数组并初始化第一个Segment，其余的Segment延迟初始化
	Segment<K,V> s0 =
	    new Segment<K,V>(loadFactor, (int)(cap * loadFactor),
	                     (HashEntry<K,V>[])new HashEntry[cap]);
	Segment<K,V>[] ss = (Segment<K,V>[])new Segment[ssize];
	UNSAFE.putOrderedObject(ss, SBASE, s0);
	this.segments = ss;
}

初始化方法有三个参数，如果用户不指定则会使用默认值，initialCapacity为16，loadFactor为0.75（负载因子，扩容时需要参考），concurrentLevel为16。

从上面的代码可以看出来，Segment数组的大小ssize是由concurrentLevel来决定的，但是却不一定等于concurrentLevel，ssize一定是大于或等于concurrentLevel的最小的2的次幂。比如：默认情况下concurrentLevel是16，则ssize为16；若concurrentLevel为14，则ssize为16；若concurrentLevel为17，则ssize为32。

put 方法

public V put(K key, V value) {
    Segment<K,V> s;
    //concurrentHashMap不允许key/value为空
    if (value == null)
        throw new NullPointerException();
    //hash函数对key的hashCode重新散列，避免差劲的不合理的hashcode，保证散列均匀
    int hash = hash(key);
    //返回的hash值无符号右移segmentShift位与段掩码进行位运算，定位segment
    int j = (hash >>> segmentShift) & segmentMask;
    if ((s = (Segment<K,V>)UNSAFE.getObject          // nonvolatile; recheck
         (segments, (j << SSHIFT) + SBASE)) == null) //  in ensureSegment
        s = ensureSegment(j);
    return s.put(key, hash, value, false);
}

从源码看出，put的主要逻辑也就两步：1. 定位segment并确保定位的Segment已初始化。2. 调用Segment的put方法。

final V put(K key, int hash, V value, boolean onlyIfAbsent) {
    HashEntry<K,V> node = tryLock() ? null :
        scanAndLockForPut(key, hash, value);
    V oldValue;
    try {
        HashEntry<K,V>[] tab = table;
        int index = (tab.length - 1) & hash;
        HashEntry<K,V> first = entryAt(tab, index);
        for (HashEntry<K,V> e = first;;) {
            if (e != null) {
                K k;
                if ((k = e.key) == key ||
                    (e.hash == hash && key.equals(k))) {
                    oldValue = e.value;
                    if (!onlyIfAbsent) {
                        e.value = value;
                        ++modCount;
                    }
                    break;
                }
                e = e.next;
            }
            else {
                if (node != null)
                    node.setNext(first);
                else
                    node = new HashEntry<K,V>(hash, key, value, first);
                int c = count + 1;
                if (c > threshold && tab.length < MAXIMUM_CAPACITY)
                    rehash(node);
                else
                    setEntryAt(tab, index, node);
                ++modCount;
                count = c;
                oldValue = null;
                break;
            }
        }
    } finally {
        unlock();
    }
    return oldValue;
}

虽然 HashEntry 中的 value 是用 volatile 关键词修饰的，但是并不能保证并发的原子性，所以 put 操作时仍然需要加锁处理。

首先第一步的时候会尝试获取锁，如果获取失败肯定就有其他线程存在竞争，则利用 scanAndLockForPut() 自旋获取锁。
在这里插入图片描述

尝试自旋获取锁。
如果重试的次数达到了 MAX_SCAN_RETRIES 则改为阻塞锁获取，保证能获取成功。

在这里插入图片描述
再结合图看看 put 的流程。

将当前 Segment 中的 table 通过 key 的 hashcode 定位到 HashEntry。
遍历该 HashEntry，如果不为空则判断传入的 key 和当前遍历的 key 是否相等，相等则覆盖旧的 value。
不为空则需要新建一个 HashEntry 并加入到 Segment 中，同时会先判断是否需要扩容。
最后会解除在 1 中所获取当前 Segment 的锁。

get 方法

public V get(Object key) {
	Segment<K,V> s; // manually integrate access methods to reduce overhead
	HashEntry<K,V>[] tab;
	int h = hash(key);
	long u = (((h >>> segmentShift) & segmentMask) << SSHIFT) + SBASE;
	if ((s = (Segment<K,V>)UNSAFE.getObjectVolatile(segments, u)) != null &&
	    (tab = s.table) != null) {
	    for (HashEntry<K,V> e = (HashEntry<K,V>) UNSAFE.getObjectVolatile
	             (tab, ((long)(((tab.length - 1) & h)) << TSHIFT) + TBASE);
	         e != null; e = e.next) {
	        K k;
	        if ((k = e.key) == key || (e.hash == h && key.equals(k)))
	            return e.value;
	    }
	}
	return null;
}

get 逻辑比较简单：

只需要将 Key 通过 Hash 之后定位到具体的 Segment ，再通过一次 Hash 定位到具体的元素上。

由于 HashEntry 中的 value 属性是用 volatile 关键词修饰的，保证了内存可见性，所以每次获取时都是最新值。

ConcurrentHashMap 的 get 方法是非常高效的，因为整个过程都不需要加锁。

在 1.8 的实现

1.8中放弃了Segment 臃肿的设计，取而代之的是采用 Node + CAS + Synchronized 来保证并发安全进行实现，结构如下：

在这里插入图片描述

只有在执行第一次 put 方法时才会调用initTable()初始化Node数组，实现如下：

private final Node<K,V>[] initTable() {
    Node<K,V>[] tab; int sc;
    while ((tab = table) == null || tab.length == 0) {
        if ((sc = sizeCtl) < 0)
            Thread.yield(); // lost initialization race; just spin
        else if (U.compareAndSwapInt(this, SIZECTL, sc, -1)) {
            try {
                if ((tab = table) == null || tab.length == 0) {
                    int n = (sc > 0) ? sc : DEFAULT_CAPACITY;
                    @SuppressWarnings("unchecked")
                    Node<K,V>[] nt = (Node<K,V>[])new Node<?,?>[n];
                    table = tab = nt;
                    sc = n - (n >>> 2);
                }
            } finally {
                sizeCtl = sc;
            }
            break;
        }
    }
    return tab;
}

也将 1.7 中存放数据的 HashEntry 改为 Node，但作用都是相同的。

其中的 val next 都用了 volatile 修饰，保证了可见性。
在这里插入图片描述
put 方法

①、根据 key 计算出 hashcode。
②、判断是否需要进行初始化。
③、f 即为当前 key 定位出的 Node，如果为空表示当前位置可以写入数据，利用 CAS 尝试写入，失败则自旋保证成功。
④、如果当前位置的 hashcode == MOVED == -1，则需要进行扩容。
⑤、如果都不满足，则利用 synchronized 锁写入数据。
⑤、如果数量大于 TREEIFY_THRESHOLD 则要转换为红黑树。

get 方法

在这里插入图片描述

根据计算出来的 hashcode 寻址，如果就在桶上那么直接返回值。
如果是红黑树那就按照树的方式获取值。
就不满足那就按照链表的方式遍历获取值。

1.8 在 1.7 的数据结构上做了大的改动，采用红黑树之后可以保证查询效率（O(logn)），甚至取消了 ReentrantLock 改为了 synchronized，这样可以看出在新版的 JDK 中对 synchronized 优化是很到位的。

总结

ConcurrentHashMap作为一种线程安全且高效的哈希表的解决方案，尤其其中的 “分段锁” 的方案，相比HashTable的全表锁在性能上的提升非常之大。

如果有收获！！！希望老铁们来个三连，点赞、收藏、转发。
创作不易，别忘点个赞，可以让更多的人看到这篇文章，顺便鼓励我写出更好的博客

七月J

关注

0
点赞
踩
1

收藏

觉得还不错? 一键收藏
0
评论
ConcurrentHashMap实现原理及源码分析

ConcurrentHashMap是Java并发包中提供的一个线程安全且高效的HashMap实现（若对HashMap的实现原理还不甚了解，可参考我的另一篇文章 HashMap实现原理及源码分析），ConcurrentHashMap在并发编程的场景中使用频率非常之高，本文就来分析下ConcurrentHashMap的实现原理，并对其实现原理进行分析。ConcurrentHashMap实现原理众所周知，哈希表是中非常高效，复杂度为O(1)的数据结构，在Java开发中，我们最常见到最频繁使用的就是HashMa
复制链接

扫一扫