JUC--ConcurrentHashMap源码分析(二)(基于JDK1.8)

1 概述

前面我们分析了ConcurrentHashMap(JDK1.7)（请参考JUC--ConcurrentHashMap源码分析(一)(基于JDK1.7)）和HashMap(JDK1.8)（请参考Java集合框架--HashMap源码分析（二）（基于JDK1.8））的源码，我们直到ConcurrentHashMap其实就是针对HashMap(JDK1.7)进行了分段加锁的方式，也就是针对HashTable中的对整个table进行加锁，改成了将table分成很多段，然后对对应的段进行加锁。

ConcurrentHashMap(JDK1.8)其实就是在HashMap(JDK1.8)的基础上，使用CAS和sychronized关键字来对table中的节点进行加锁，这里就进一步减小了锁的粒度。下面我们就开始来看一下ConcurrentHashMap(JDK1.8)的具体实现。

2 数据结构

ConcurrentHashMap(JDK1.8)在数据的结构上加入了红黑树，从而对查询的效率进行了进一步优化，同时屏弃了JDK1.7中的Segment分段加锁的方式，改成CAS和sychronized来保证并发安全性。具体的数据结构图如下：

3 内部类

（1）Node

static class Node<K,V> implements Map.Entry<K,V> {
        final int hash;
        final K key;
        volatile V val;
        volatile Node<K,V> next;
... ... 

Node其实和HashEntry是相同的，这里就不多说了。

（2）TreeNode

    static final class TreeNode<K,V> extends Node<K,V> {
        TreeNode<K,V> parent;  // red-black tree links
        TreeNode<K,V> left;
        TreeNode<K,V> right;
        TreeNode<K,V> prev;    // needed to unlink next upon deletion
        boolean red;

        TreeNode(int hash, K key, V val, Node<K,V> next,
                 TreeNode<K,V> parent) {
            super(hash, key, val, next);
            this.parent = parent;
        }
    ... ... 

从上面的源码我们可以看出，TreeNode静态内部类实现了典型的红黑树的数据结构。

（3）TreeBin

static final class TreeBin<K,V> extends Node<K,V> {
        TreeNode<K,V> root;
        volatile TreeNode<K,V> first;
        volatile Thread waiter;
        volatile int lockState;
        // values for lockState
        static final int WRITER = 1; // set while holding write lock
        static final int WAITER = 2; // set when waiting for write lock
        static final int READER = 4; // increment value for setting read lock
... ... 

TreeBean相当于一个TreeNode的容器，里面也提供了针对红黑树结构的添加和删除的操作函数。

4属性

针对属性这里就不做统一分析说明了，其实和HashMap(JDK1.8)中的属性类似。

5 构造函数

针对ConcurrentHashMap的构造函数，我们仅仅分析一个比较核心的构造函数即可。

public ConcurrentHashMap(int initialCapacity,
                             float loadFactor, int concurrencyLevel) {

        //判断参数的合法性
        if (!(loadFactor > 0.0f) || initialCapacity < 0 || concurrencyLevel <= 0)
            throw new IllegalArgumentException();
        if (initialCapacity < concurrencyLevel)   // Use at least as many bins
            initialCapacity = concurrencyLevel;   // as estimated threads
        
        初始化table的大小
        long size = (long)(1.0 + (long)initialCapacity / loadFactor);
        int cap = (size >= (long)MAXIMUM_CAPACITY) ?
            MAXIMUM_CAPACITY : tableSizeFor((int)size);
        this.sizeCtl = cap;
    }

上面的构造函数有一个比较陌生的参数concurrencyLevel，这个参数我们可以理解成用于控制有多少个线程可以同时操作Current HashMap。

6 核心函数

针对核心函数，我们这里还是分析put和get两种函数。

6.1 put函数

首先，我们直接上源码，并在源码中对关键逻辑处进行注释。

final V putVal(K key, V value, boolean onlyIfAbsent) {
        if (key == null || value == null) throw new NullPointerException();
        int hash = spread(key.hashCode());
        int binCount = 0;
        for (Node<K,V>[] tab = table;;) {
            Node<K,V> f; int n, i, fh;
			
	    //如果table不存在或者为空，则初始化table
            if (tab == null || (n = tab.length) == 0)
                tab = initTable();
			
	    //如果table对应位置的Node为空，则直接在对应位置使用CAS设置Node。
            else if ((f = tabAt(tab, i = (n - 1) & hash)) == null) {
                if (casTabAt(tab, i, null,
                             new Node<K,V>(hash, key, value, null)))
                    break;                   // no lock when adding to empty bin
            }
			
	    //如果当前节点的hash == MOVED == -1，则需要进行扩容
            else if ((fh = f.hash) == MOVED)
                tab = helpTransfer(tab, f);
            else {
                V oldVal = null;
				
                //对table对应位置的节点Node进行加锁
                synchronized (f) {
					
                    //table对应位置的节点是普通的Node结构
                    if (tabAt(tab, i) == f) {
                        if (fh >= 0) {
                            binCount = 1;
							
                            /**
                             * 在对应链表的对应位置插入节点，如果存在key和hash相等，则替换节点的value值，
                             * 如果不存在key和hash相等的节点，则生成新的节点，并让最后一个节点的下一个节点指向新
                             * 节点。
                             */
                            for (Node<K,V> e = f;; ++binCount) {
                                K ek;
                                if (e.hash == hash &&
                                    ((ek = e.key) == key ||
                                     (ek != null && key.equals(ek)))) {
                                    oldVal = e.val;
                                    if (!onlyIfAbsent)
                                        e.val = value;
                                    break;
                                }
                                Node<K,V> pred = e;
                                if ((e = e.next) == null) {
                                    pred.next = new Node<K,V>(hash, key,
                                                              value, null);
                                    break;
                                }
                            }
                        }
						
                        //table对应位置的节点是红黑树结构
                        else if (f instanceof TreeBin) {
                            Node<K,V> p;
                            binCount = 2;
							
                            //采用红黑树插入节点的方式插入值
                            if ((p = ((TreeBin<K,V>)f).putTreeVal(hash, key,
                                                           value)) != null) {
                                oldVal = p.val;
                                if (!onlyIfAbsent)
                                    p.val = value;
                            }
                        }
                    }
                }
                if (binCount != 0) {
					
                    //当链表长度大于需要转换成红黑树的阀值的时候转换成红黑树
                    if (binCount >= TREEIFY_THRESHOLD)
                        treeifyBin(tab, i);
                    if (oldVal != null)
                        return oldVal;
                    break;
                }
            }
        }
        addCount(1L, binCount);
        return null;
    }

从上面的代码我们可以看出，这里替代了之前的对Segment进行加锁，而是当table对应位置的Node为空的时候直接使用CAS来进行设置，当不为空的时候就对table对应位置的节点加锁，然后遍历节点进行操作。

6.2 get函数

首先来看下源码：

public V get(Object key) {
        Node<K,V>[] tab; Node<K,V> e, p; int n, eh; K ek;
		
	//获取key对应的hash值
        int h = spread(key.hashCode());
		
	//table数组不为空，并且hash值对应的节点存在
        if ((tab = table) != null && (n = tab.length) > 0 &&
            (e = tabAt(tab, (n - 1) & h)) != null) {
				
	    //如果对table数组中的节点的hash和key都和要查找的key和hash相等，这个时候就直接返回table数组节点的value	
            if ((eh = e.hash) == h) {
                if ((ek = e.key) == key || (ek != null && key.equals(ek)))
                    return e.val;
            }
			
	    //eh < 0,是红黑树，按照红黑树的方式获取
            else if (eh < 0)
                return (p = e.find(h, key)) != null ? p.val : null;
			
	    //循环hash对应table位置的链表，如果存在key和hash相等的节点直接返回value
            while ((e = e.next) != null) {
                if (e.hash == h &&
                    ((ek = e.key) == key || (ek != null && key.equals(ek))))
                    return e.val;
            }
        }
        return null;
    }

get方法的实现比较简单，我们这里就不做过多的解释了。

7 总结

JDK1.8版本的ConcurrentHashMap的数据结构已经接近HashMap，，ConcurrentHashMap只是增加了同步的操作来控制并发，从JDK1.7版本的ReentrantLock+Segment+HashEntry，到JDK1.8版本中synchronized+CAS+Node+红黑树。

现总结下针对ConcurrentHashMap的JDK1.7和JDK1.8的实现区别：

1. JDK1.8的实现降低锁的粒度，JDK1.7版本锁的粒度是基于Segment的，包含多个HashEntry，而JDK1.8锁的粒度就是HashEntry（首节点）
2. JDK1.8版本的数据结构变得更加简单，使得操作也更加清晰流畅，因为已经使用synchronized来进行同步，所以不需要分段锁的概念，也就不需要Segment这种数据结构了，由于粒度的降低，实现的复杂度也增加了
3. JDK1.8使用红黑树来优化链表，基于长度很长的链表的遍历是一个很漫长的过程，而红黑树的遍历效率是很快的，代替一定阈值的链表，这样形成一个最佳拍档
4. JDK1.8为什么使用内置锁synchronized来代替重入锁ReentrantLock，我觉得有以下几点：

• 因为粒度降低了，在相对而言的低粒度加锁方式，synchronized并不比ReentrantLock差，在粗粒度加锁中ReentrantLock可能通过Condition来控制各个低粒度的边界，更加的灵活，而在低粒度中，Condition的优势就没有了
• JVM的开发团队从来都没有放弃synchronized，而且基于JVM的synchronized优化空间更大，使用内嵌的关键字比使用API更加自然
• 在大量的数据操作下，对于JVM的内存压力，基于API的ReentrantLock会开销更多的内存，虽然不是瓶颈，但是也是一个选择依据