ConcurrentHashMap并发安全的实现原理~java7

前言

最近看到一些文章，聊到ConcurrentHashMap的时候，总会说：在jdk8之前，ConcurrentHashMap采用的是分段锁来保证并发安全性。而jdk8放弃了分段锁，通过sycronized关键字+CAS来保证并发安全性。虽然大概是这么个意思，但是感觉不够透彻，所以也想斗胆谈谈我的个人见解。

ConcurrentHashMap in Java7

先说明，我看的是jdk1.7.0_79版本的。
默认构造方法

	public ConcurrentHashMap() {
        this(DEFAULT_INITIAL_CAPACITY, DEFAULT_LOAD_FACTOR, DEFAULT_CONCURRENCY_LEVEL);
    }
    
    @SuppressWarnings("unchecked")
    public ConcurrentHashMap(int initialCapacity,
                             float loadFactor, int concurrencyLevel) {
        if (!(loadFactor > 0) || initialCapacity < 0 || concurrencyLevel <= 0)
            throw new IllegalArgumentException();
        if (concurrencyLevel > MAX_SEGMENTS)
            concurrencyLevel = MAX_SEGMENTS;
        // Find power-of-two sizes best matching arguments
        int sshift = 0;
        int ssize = 1;
        // 由并发级别，计算segments数组的大小
        while (ssize < concurrencyLevel) {
            ++sshift;
            ssize <<= 1;
        }
        this.segmentShift = 32 - sshift;
        this.segmentMask = ssize - 1;
        if (initialCapacity > MAXIMUM_CAPACITY)
            initialCapacity = MAXIMUM_CAPACITY;
        // 对调用者预期容量分摊到每个segment的table容量进行计算
        int c = initialCapacity / ssize;
        // 对总容量进行校验，向上取整，以确保能存下调用者预期的元素个数
        if (c * ssize < initialCapacity)
            ++c;
        // 将每个segment的元素容量处理为2的幂次个
        int cap = MIN_SEGMENT_TABLE_CAPACITY;
        while (cap < c)
            cap <<= 1;
        // create segments and segments[0]
        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); // ordered write of segments[0]
        this.segments = ss;
    }

默认构造器，使用了一个默认的并发级别的常量常数，值为16. 由其调用的另一个构造器，我们知道，该并发级别决定了segments数组的大小，同时该大小被处理成2的幂次了。并创建了segments[0]，传入了负载因子和扩容阈值。
再来看看内部Segment类
构造器

    static final class Segment<K,V> extends ReentrantLock implements Serializable {
		Segment(float lf, int threshold, HashEntry<K,V>[] tab) {
            this.loadFactor = lf;
            this.threshold = threshold;
            this.table = tab;
        }
        ...
    }

负载因子loadFactor、阈值threshold、hash表table，一应俱全，是不是想到了HashMap，等会儿再来聊这个。再看到类的定义，Segment还继承了ReentrantLock，它自身就是锁的实现。
然后回过头来看看ConcurrentHashMap的put方法

    public V put(K key, V value) {
        Segment<K,V> s;
        if (value == null)
            throw new NullPointerException();
        int hash = hash(key);
        // 第一次hash，到对应的segment
        int j = (hash >>> segmentShift) & segmentMask;
        if ((s = (Segment<K,V>)UNSAFE.getObject          // nonvolatile; recheck
             (segments, (j << SSHIFT) + SBASE)) == null) //  in ensureSegment
             // 由于默认构造器只创建了一个Segment:s0，因此在使用之前需要先确保该位置的Segment对象存在。这里是延迟实例化设计。
            s = ensureSegment(j);
        return s.put(key, hash, value, false);
    }

在ConcurrentHashMap#put方法中，只是找到对应的segment，还没有存放当前元素，而是调用Segment#put方法来实现。

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;
                // 第二次hash，找到在hash表中的位置
                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)
                        	// 超出阈值，扩容并重新hash
                            rehash(node);
                        else
                        	// 否则通过CAS操作放到该槽中
                            setEntryAt(tab, index, node);
                        ++modCount;
                        count = c;
                        oldValue = null;
                        break;
                    }
                }
            } finally {
            	// 解锁
                unlock();
            }
            return oldValue;
        }

到这里，可以给大家画张图来更直观的反映ConcurrentHashMap的数据结构

从上面的数据结构，我们可以发现，当并发级别设置为1时，只有一个Segment，即只存在一把锁，只存在一个hash表数组table。其效果几乎等同与Collections.syncronizedMap。只是在读取元素时没有加锁，通过CAS+volatile来保证可见性。而Collections.syncronizedMap会加锁。

总结

1. 在Java7中ConcurrentHashMap的数据结构确实是数组+链表。
2. 数据的并发安全由Segment保证，而Segment是一把ReentrantLock锁。
3. 保证并发安全的核心思想是：分段锁。
   分段锁：个人认为这是一种分而治之的思想体现。对于HashMap而言，把原来需要对所有元素进行加锁的过程进行分解。只对某一部分的数据进行加锁。每个部分的数据单独保证安全性，互不干扰，互不影响。这个也可以类比到数据库的表锁和行锁。核心要义就是通过减小锁粒度，来减小竞争。
   而Segment就是该思想的实现。把一个大的hash表按照并发级别进行拆分成多个hash表分别管理，每一个Segment只负责其中一部分的数据。
4. Segment分段锁实现下的ConcurrentHashMap的劣势：
   • 寻找元素需要经过两次hash
   • 并发级别的合理设置问题。虽然提供了默认的并发级别，但是是否在大多数场景下都适用？归根结底，就是需要用户自己来评估需要多少把锁来分段治理的问题。
   • 在存储成本比HashMap高。每个Segment管理的最少容量是2，而默认的并发级别为16，即16个Segment。假如我只需要存储的是16个元素，那么ConcurrentHashMap会需要占用2倍的存储空间。

后记

由于Segment实现的弊端，Java8痛下杀手，直接放弃了Segment。而是采用了更加细粒度的分段锁，而且也更加巧妙。通过syncronized + CAS操作来实现，性能得到大幅提升。下一篇，咱们接着聊Java8的ConcurrentHashMap！