ConcurrentHashMap实现原理——Java并发容器

最新推荐文章于 2024-05-15 17:09:14 发布

nogos

最新推荐文章于 2024-05-15 17:09:14 发布

阅读量1.2k

点赞数 4

分类专栏： Java并发编程 Java基础文章标签： ConcurrentHashMap JDK 1.7 HashMap死循环

本文链接：https://blog.csdn.net/sunxianghuang/article/details/52024624

版权

Java基础同时被 2 个专栏收录

21 篇文章 16 订阅

订阅专栏

Java并发编程

9 篇文章 0 订阅

订阅专栏

ConcurrentHashMap是线程安全且高效的HashMap。我们一起研究一下该容器是如何在保证线程安全的同时又能保证高效的操作。

为什么要使用ConcurrentHashMap

在并发编程中使用HashMap可能导致程序死循环。而使用线程安全的HashTable效率又非常低下，基于以上两个原因，便有了ConcurrentHashMap的登场机会。

（1）线程不安全的HashMap
在多线程环境下，使用HashMap进行put操作会引起死循环，导致CPU利用率接近100%，所以在并发情况下不能使用HashMap。例如，执行以下代码会引起死循环。

注：源码来自JDK 1.7

public class Test { 
	public static void main(String[] args) throws InterruptedException {
		final HashMap<String, String> map = new HashMap<String, String>(2);
		Thread t = new Thread(new Runnable() {
			@Override
			public void run() {
				for (int i = 0; i < 100; i++) {//开启100个线程，同时向map中添加元素
					new Thread(new Runnable() {
						@Override
						public void run() {
							for(int k=0;k<1000;k++){
								map.put(UUID.randomUUID().toString(), "");
							} 
						}
					}, "ftf" + i).start();
				}
			}
		}, "ftf");
		t.start();
		t.join();
	} 
}

HashMap在并发执行put操作时会引起死循环，是因为多线程会导致HashMap的Entry链表形成环形数据结构，一旦形成环形数据结构，Entry的next节点永远不为空，就会产生死循环获取Entry。

产生死循环的过程

    /**对HashMap进行容量扩充
     * Transfers all entries from current table to newTable.
     */
    void transfer(Entry[] newTable) {
        Entry[] src = table;
        int newCapacity = newTable.length;
        for (int j = 0; j < src.length; j++) {//遍历原table中的所有表头
            Entry<K,V> e = src[j];
            if (e != null) {
                src[j] = null;
                do {//依次将链表中的元素，重新添加到新的table中
                    Entry<K,V> next = e.next;//          代码 1
                    int i = indexFor(e.hash, newCapacity);
                    e.next = newTable[i];
                    newTable[i] = e;
                    e = next;
                } while (e != null);
            }
        }
    }

首先，假设我们有两个并发的线程同时进行容量扩充，因此每个线程都拥有一个newTable。状态如下所示：

再假设，线程1和线程2都执行了代码1。状态如下所示：

接着，线程1执行完整个链表转移操作，线程2什么都不做。状态如下所示：

注：这里假定元素E 1和E 2重新映射后在newTable中的索引位置不变（或者说一致），由于是头插法，故元素逆序。

接着，线程2向newTable 2中插入一个元素。状态如下所示：

注意：特别注意e 2和next 2的指针位置。

因为e 2！=null，因此线程2继续转移元素。状态如下所示：

发现没有，此状态与上上步的状态一样，因此接下就进入了死循环。

（2）效率低下的HashTable
HashTable容器使用synchronized来保证线程安全，但在线程竞争激烈的情况下HashTable的效率非常低下。因为当一个线程访问HashTable的同步方法，其他线程也访问HashTable的同步方法时，会进入阻塞或轮询状态。如线程1使用put进行元素添加，线程2不但不能使用put方法添加元素，也不能使用get方法来获取元素，所以竞争越激烈效率越低。
（3）ConcurrentHashMap的锁分段技术可有效提升并发访问率HashTable容器在竞争激烈的并发环境下表现出效率低下的原因是所有访问HashTable的线程都必须竞争同一把锁，假如容器里有多把锁，每一把锁用于锁容器其中一部分数据，那么当多线程访问容器里不同数据段的数据时，线程间就不会存在锁竞争，从而可以有效提高并发访问效率，这就是ConcurrentHashMap所使用的锁分段技术。首先将数据分成一段一段地存储，然后给每一段数据配一把锁，当一个线程占用锁访问其中一个段数据的时候，其他段的数据也能被其他线程访问。

ConcurrentHashMap的结构

public class ConcurrentHashMap<K, V> extends AbstractMap<K, V>
        implements ConcurrentMap<K, V>, Serializable {
    /**每个分段(segment）对应一个独立的hashTable
     * The segments, each of which is a specialized hash table.
     */
    final Segment<K,V>[] segments;//分段数组
    //......
    static final class Segment<K,V> extends ReentrantLock implements Serializable {
        transient volatile HashEntry<K,V>[] table;//链表头的集合
    //.......
    }
    static final class HashEntry<K,V> {
        final int hash;
        final K key;
        volatile V value;
        volatile HashEntry<K,V> next;//双向链表
    //......
    }
}

结构图：

一个ConcurrentHashMap里包含一个Segment数组。Segment是一种可重入锁（ReentrantLock），扮演锁的角色；

Segment的结构和HashMap类似，是一种数组和链表结构。一个Segment里包含一个HashEntry数组，每个HashEntry是一个链表结构的元素，每个Segment守护着一个HashEntry数组里的元素，当对HashEntry数组的数据进行修改时，必须首先获得与它对应的Segment锁。

ReentrantLock（重入锁）

重入锁ReentrantLock，顾名思义，就是支持重进入的锁，它表示该锁能够支持一个线程对资源的重复加锁。除此之外，该锁的还支持获取锁时的公平和非公平性选择。

synchronized关键字隐式的支持重进入，比如一个synchronized修饰的递归方法，在方法执行时，执行线程在获取了锁之后仍能连续多次地获得该锁。

ReentrantLock虽然没能像synchronized关键字一样支持隐式的重进入，但是在调用lock()方法时，已经获取到锁的线程，能够再次调用lock()方法获取锁而不被阻塞。

这里提到一个锁获取的公平性问题，如果在绝对时间上，先对锁进行获取的请求一定先被满足，那么这个锁是公平的，反之，是不公平的。公平的获取锁，也就是等待时间最长的线程最优先获取锁，也可以说锁获取是顺序的。ReentrantLock提供了一个构造函数，能够控制锁是否是公平的。

事实上，公平的锁机制往往没有非公平的效率高，但是，并不是任何场景都是以TPS作为唯一的指标，公平锁能够减少“饥饿”发生的概率，等待越久的请求越是能够得到优先满足。

ConcurrentHashMap的操作

put

    public V put(K key, V value) {
        Segment<K,V> s;
        if (value == null)
            throw new NullPointerException();//value不允许为null
        int hash = hash(key.hashCode());//通过散列函数计算哈希值
        //接下来，进行再散列定位segment位置，并获取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);//如果对应位置segment为null，就创建segment
        //将数据存入对应segment，调用Segment<K,V>的put方法
        return s.put(key, hash, value, false);
    }

之所以要进行再散列，目的是减少散列冲突，使元素能够均匀分布在不同的segment上，从而提高容器存取效率。

Segment<K,V>的put方法

        final V put(K key, int hash, V value, boolean onlyIfAbsent) {
            HashEntry<K,V> node = tryLock() ? null :
                scanAndLockForPut(key, hash, value);//这一步会确保获取到当前segment的锁
            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;;) {
                    //遍历链表，有则替换，无则添加
                    //........
                }
            } finally {
                unlock();//修改完segment后解锁
            }
            return oldValue;
        }

扩容

ConcurrentHashMap不会想HashMap那样对整个容器进行扩容，而只对某个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.hashCode());
        long u = (((h >>> segmentShift) & segmentMask) << SSHIFT) + SBASE;//再散列定位segment
        if ((s = (Segment<K,V>)UNSAFE.getObjectVolatile(segments, u)) != null &&
            (tab = s.table) != null) {//获取segment及其table
            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操作的高效之处在于整个get过程不需要加锁。我们知道HashTable容器get方法是需要加锁的（synchronized），那么ConcurrentHashMap的get操作是如何做到不加锁的呢？

原因是它将要使用的共享变量定义为volatile类型，这样就保证了线程之间的可见性。

如:HashEntry的value和next

        volatile V value;
        volatile HashEntry<K,V> next;

Segment的table

        transient volatile HashEntry<K,V>[] table;

size

    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;
    }

如果要统计整个ConcurrentHashMap里元素的大小，就必须统计所有Segment里元素的大小后求和。多线程场景下，是不是直接把所有Segment的count相加就可以得到整个ConcurrentHashMap大小了呢？不是的，因为在累加过程中可能累加前使用的count发生了变化，那么统计结果就不准了。所以，最安全的做法是在统计size的时候把所有Segment的put、remove和clean方法全部锁住，但是这种做法显然非常低效。
因为在累加count操作过程中，之前累加过的count发生变化的几率非常小，所以ConcurrentHashMap的做法是先尝试2次通过不锁住Segment的方式来统计各个Segment大小，如果统计的过程中，容器的count发生了变化，则再采用加锁的方式来统计所有Segment的大小。那么ConcurrentHashMap是如何判断在统计的时候容器是否发生了变化呢？使用modCount变量，在put、remove和clean方法里操作元素前都会将变量modCount进行加1，那么在统计size前后比较modCount是否发生变化，从而得知容器的大小是否发生变化。

ConcurrentHashMap 实现高并发的总结

基于通常情形而优化
在实际的应用中，散列表一般的应用场景是：除了少数插入操作和删除操作外，绝大多数都是读取操作，而且读操作在大多数时候都是成功的。正是基于这个前提，ConcurrentHashMap 针对读操作做了大量的优化。通过 HashEntry 对象的不变性和用 volatile 型变量协调线程间的内存可见性，使得大多数时候，读操作不需要加锁就可以正确获得值。这个特性使得 ConcurrentHashMap 的并发性能在分离锁的基础上又有了近一步的提高。
总结
ConcurrentHashMap 是一个并发散列映射表的实现，它允许完全并发的读取，并且支持给定数量的并发更新。相比于 HashTable 和用同步包装器包装的 HashMap（Collections.synchronizedMap(new HashMap())），ConcurrentHashMap 拥有更高的并发性。在 HashTable 和由同步包装器包装的 HashMap 中，使用一个全局的锁来同步不同线程间的并发访问。同一时间点，只能有一个线程持有锁，也就是说在同一时间点，只能有一个线程能访问容器。这虽然保证多线程间的安全并发访问，但同时也导致对容器的访问变成串行化的了。
在使用锁来协调多线程间并发访问的模式下，减小对锁的竞争可以有效提高并发性。有两种方式可以减小锁的竞争：
1、减小请求同一个锁的频率。

2、减少持有锁的时间。

ConcurrentHashMap 的高并发性主要来自于两个方面：
1、用分离锁实现多个线程间的更深层次的共享访问。

使用分离锁，减小了请求同一个锁的频率。
2、通过对同一个 Volatile 变量的写 / 读访问，协调不同线程间读 / 写操作的内存可见性。

通过 Volatile 变量的读 / 写来协调内存可见性，使得读操作大多数时候不需要加锁就能成功获取到需要的值。由于散列映射表在实际应用中大多数操作都是成功的读操作，所以既可以减少请求同一个锁的频率，也可以有效减少持有锁的时间。
通过减小请求同一个锁的频率和尽量减少持有锁的时间，使得 ConcurrentHashMap 的并发性相对于 HashTable 和用同步包装器包装的 HashMap有了质的提高。

参考：

http://ifeve.com/hashmap-infinite-loop/

http://www.ibm.com/developerworks/cn/java/java-lo-concurrenthashmap/

《并发编程的艺术》