ConcurrentHashMap如何实现高效的线程安全

此前已经介绍了Java集合框架的典型，并且也分析了比较流行的Map实现方法HashMap，让大家进一步的了解了使用方法和底层原理，并且简单讲述了线程方面的问题，此文章将主要围绕线程，亦或是并发的角度去介绍。

之前所介绍大多数都是线程不安全的，但也有像HashTable这样安全，但是性能很差，成本很高的，所以Java内部也提供了并发包，为高度并发需求提供了更加全面的工具支持。

那么，应该如何保证线程安全，Concurrent包下的ConcurrentHashMap又是如何实现高效的线程安全的？？？

简介

Java提供了不同层面的线程安全支持。在传统集合框架内部，可以调用Collections工具类提供的包装方法来获取一个同步的包装容器，但都是利用非常粗粒度的同步方式，在高并发情况下，性能相对比较低。
此外，更加普遍的选择是用并发包提供的线程安全容器类，它提供了：

1. 并发容器：ConcurrentHashMap，CopyOnWriteArrayList
2. 线程安全队列(Queue/Deque)：ArrayBlockingQueue、SynchronousQueue
3. 各种有序容器的线程安全版本等。

保证线程安全，最简单的就是使用synchronize，到基于更加精细化的，比如基于分离锁实现的ConcurrentHashMap等并发实现等。具体要看实际开发的场景需求，总体来说，并发包内提供的容器通用场景，远胜于早期的简单同步实现。

分离锁：在某些情况下，可以将锁分解技术进一步扩展为对一组独立对象上的锁进行分解，这种情况称为锁分段。例如ConcurrencyHashMap是由一个包含16个锁的数组实现，每个锁保护所有散列桶的1/16，其中第N个散列桶由第（N mod 16）个锁来保护。假设所有关键字的时间均匀分布，那么相当于把锁的请求减少到原来的1/16，可以支持多达16个的并发写入。

线程安全和并发，是java面试中的必考点，但是对于ConcurrentHashMap等等的并发容器也在不断的演进，因此也不能一概而论。

面试角度来说：
想要深入思考并且回答这个问题及其扩展方面，至少需要：

• 理解基本的线程安全工具
• 理解传统集合框架并发编程中Map存在的问题，了解简单同步方式的不足
• 梳理并发包内，尤其是ConcurrentHashMap自身的演进，目前的很多分析资料还是基于其早期版本
• 掌握ConcurrentHashMap自身的演进，目前的很多分析资料还是基于其早期版本。

知识扩展
为什么需要ConcurrentHashMap？

我们之前说过HashTable是可以保证线程安全的，但是性能较低，或者可以说是比较耿直，在底层像get、 put、 remove 等的操作，在底层都是加上了各种synchronize。简单来说，这就导致了所有并发操作都需要竞争同一把锁，一个线程在进行同步操作时其他线程只能等待，这就大大降低了效率。

前面已经提到了HashMap不是线程安全的，并发情况会让CPU占用100%，那么能不能利用Collections提供的同步包装来解决问题呢?

可以看以下的代码：

观察发现这个同步包装器只是利用输入Map构造了另一个同步版本，所有操作虽然不再声明成为synchronized方法，但是还是利用了this作为互斥的mutex，没有真正的改进。

因此HashTable确实可以保证线程安全，但无法保证高并发环境的有效利用。

ConCurrentHashMap分析

首先强调，ConcurrentHashMap的设计一直都在演化，因此这里将比较分析结构，实现机制等方面，进行不同版本的讲述。

在最早的ConcurrentHashMap，其实现是基于：
1、分离锁，也就是将内部进行分段(Segment)，里面则是HashEntry的数组，和HashMap类似，哈希相同的条目也是以链表的形式存放。
2、HashEntry内部使用volatile的value字段来保证可见性，也利用了不可变对象的机制来改进利用Unsafe提供的底层能力，比如volatile access。去直接完成部分操作，以最优化性能，毕竟Unsafe中的很多操作都是JVM intrinsic优化过的

明显看出它避免了HashTable整体同步的问题，提高了性能。

在构造的时候，Segment的数量由concurrentcyLevel决定，默认是16，也可以在相应构造函数直接指定。

接下来看一下ConcurrentHashMap下的get源码：

对于put操作，为了避免二次哈希导致哈希碰撞，使用Unsafe，直接获取Node，然后进行线程安全的put操作：

public V put(K key, V value) {
        return putVal(key, value, false);
    }

    /** Implementation for put and putIfAbsent */
    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;
            if (tab == null || (n = tab.length) == 0)
                tab = initTable();
            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
            }
            else if ((fh = f.hash) == MOVED)
                tab = helpTransfer(tab, f);
            else {
                V oldVal = null;
                synchronized (f) {
                    if (tabAt(tab, i) == f) {
                        if (fh >= 0) {
                            binCount = 1;
                            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;
                                }
                            }
                        }
                        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;
    }

得出以下结论：
1、ConcurrentHashMap会获取再入锁，以保证数据一致性，Segment本身就是基于ReentrantLock的扩展，所以在并发修改的时候，响应的Segment是被锁定的。

2、在最初阶段，进行重复性的扫描，以确定响应的Key值是否已经在数组里面，进而决定是更新还是放置操作，你可以在代码里看到相应的注释。

3、ConcurrentHashMap的扩容是单独的不是整体的

另外一个map的size方法同样需要关注，它的实现涉及分离锁的一个副作用。

如果不进行同步，简单计算所有Segment的总值，可能会因为put并发导致结果运算不准确，但是直接锁定所有Segment进行计算，就会变得十分昂贵。其实，分离锁也限制了Map的初始化。

所以，ConcurrentHashMap的实现是通过重试机制（ RETRIES_BEFORE_LOCK，指定重试次数2），来试图获得可靠值。

那么，在JDK8和之后的版本，ConcurrentHashMap的变化也来简单的介绍一下：

• 总体结构上，和map差不多，都是很多桶数组里面放了很多链表，但是粒度上
  更加细致
• 内部仍然通过Segment保证序列化的兼容性
• 不再使用Segment。初始化变得简单，避免了额外开销
• 数据存储利用volatile来保证可见性
• 使用CAS等操作，在特定场景进行无锁并发操作
• 使用Unsafe、LongAddr之类底层手段，进行极端情况的优化

先看看现在的数据存储内部实现，我们可以发现Key是final的，因为在生命周期中，一个条目的Key发生变化是不可能的；与此同时val，则声明为volatile，以保证可见性

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(int hash, K key, V val, Node<K,V> next) {
            this.hash = hash;
            this.key = key;
            this.val = val;
            this.next = next;
        }

        public final K getKey()       { return key; }
        public final V getValue()     { return val; }
        public final int hashCode()   { return key.hashCode() ^ val.hashCode(); }
        public final String toString(){ return key + "=" + val; }
        public final V setValue(V value) {
            throw new UnsupportedOperationException();
        }

        public final boolean equals(Object o) {
            Object k, v, u; Map.Entry<?,?> e;
            return ((o instanceof Map.Entry) &&
                    (k = (e = (Map.Entry<?,?>)o).getKey()) != null &&
                    (v = e.getValue()) != null &&
                    (k == key || k.equals(key)) &&
                    (v == (u = val) || v.equals(u)));
        }

        /**
         * Virtualized support for map.get(); overridden in subclasses.
         */
        Node<K,V> find(int h, Object k) {
            Node<K,V> e = this;
            if (k != null) {
                do {
                    K ek;
                    if (e.hash == h &&
                        ((ek = e.key) == k || (ek != null && k.equals(ek))))
                        return e;
                } while ((e = e.next) != null);
            }
            return null;
        }
    }

可以发现，Key是final的，在生命周期中，一个条目的key发生变化是不可能的，同时val，则声明为voliatile，以保证可见性

初始化的实现操作在initTable里，这是一个典型的CAS使用场景，利用volatile的sizeCtl作为互斥手段：如果发现竞争性的初始化，就spin在哪里，等待条件恢复，否则利用CAS设置排他标志。如果成功就初始化，不然就重试。

CAS：CAS（Compare and Swap），即比较并替换，实现并发算法时常用到的一种技术，Doug lea大神在java同步器中大量使用了CAS技术，鬼斧神工的实现了多线程执行的安全性。

当bin为空到时候，同样是没有必要锁定，也是以CAS操作去放置。

在不断的JDK更新中synchronize的性能已经超过了ReentrantLock。

与此同时，在Unsafe内也进行了优化，例如tabAt：

static final <K,V> Node<K,V> tabAt(Node<K,V>[] tab, int i) {
        return (Node<K,V>)U.getObjectVolatile(tab, ((long)i << ASHIFT) + ABASE);
    }

再看看size操作，可以发现真正的逻辑在sunCount中，那么sumCount做了什么呢？