java并发系列—concurrenthashmap（jad 1.7）

concurrenthashmap（jdk1.7）

HashTable与ConcurrentHashMap的对比

HashTable本身是线程安全的，写过Java程序的都知道通过加Synchronized关键字实现线程安全，这样对整张表加锁实现同步的一个缺陷就在于使程序的效率变得很低。这就是为什么Java中会在1.5后引入ConcurrentHashMap（jdk1.7）的原因。

ConcurrentHashMap主要有三大结构：整个Hash表，segment（段），HashEntry（节点）。每个segment就相当于一个HashTable。

hashentry类

static final class HashEntry<K,V> { 
        final K key;                 // 声明 key 为 final 型
        final int hash;              // 声明 hash 值为 final 型 
        volatile V value;           // 声明 value 为 volatile 型，因此get方法不用加锁
        final HashEntry<K,V> next;  // 声明 next 为 final 型 ，只有一个指针所以为单列表结构

        HashEntry(K key, int hash, HashEntry<K,V> next, V value)  { 
            this.key = key; 
            this.hash = hash; 
            this.next = next; 
            this.value = value; 
        } 
 }

每个HashEntry代表Hash表中的一个节点，在其定义的结构中可以看到，除了value值没有定义final，其余的都定义为final类型，我们知道Java中关键词final修饰的域成为最终域。用关键词final修饰的变量一旦赋值，就不能改变，也称为修饰的标识为常量。这就意味着我们删除或者增加一个节点的时候，就必须从头开始重新建立Hash链（头插法），因为next引用值需要改变

由于这样的特性，所以插入Hash链中的数据都是从头开始插入的。例如将A,B,C插入空桶中，插入后的结构为：

segment类（源码待补充）

其中有一个 Segment 数组，每个 Segment 中都有一个锁，因此 Segment 相当于一个多线程安全的 HashMap，采用分段加锁。每个 Segment 中有一个 Entry 数组，Entry 中成员 value 是volatile 修饰，其他成员通过 final 修饰。get 操作不用加锁（采用volatile，之后会详解），put 和 remove 操作需要加锁，因为 value 通过 volatile 保证可见性。

这样我们在对 segment1 操作的时候，同时也可以对 segment2 中的数据操作，这样效率就会高很多。

​ Segment 类继承于 ReentrantLock 类，从而使得 Segment 对象能充当锁的角色。Put 和remove 方法中有 lock()和 unlock()（都是使用的 this 对象，lock()在代码开始，unlock在 finally 中）。

底层结构： Segment 数组 + HashEntry 数组 + 链表（数组 + 链表是HashMap 的结构）

​ segments 数组的长度 size 通过 concurrencyLevel(并发等级默认是 16)计算得出。为了能通过按位与（length- 1的低位掩码）的哈希算法来定位 segments 数组的索引，必须保证 segments 数组的长度是2 的 N 次方（power-of-two size），所以必须计算出一个是大于或等于 concurrencyLevel的最小的 2 的 N 次方值来作为 segments 数组的长度。

​ 初始化每个 Segment。输入参数 initialCapacity 是 ConcurrentHashMap 的初始化容量，loadfactor 是每个 segment 的负载因子，在构造方法里需要通过这两个参数来初始化数组中的每个 segment。segment 里 HashEntry 数组的长度，它等于 initialCapacity 除以 ssize的倍数（总大小除以 segments 数组长度），HashEntry 的长度也是 2 的 N 次方

对比hashtable的get方法的改进

​ 我们知道 HashTable 容器的 get 方法是需要加锁的，那么 ConcurrentHashMap 的 get操作是如何做到不加锁的呢？原因是它的 get 方法里将要使用的共享变量都定义成volatile，之所以不会读到过期的值，是根据 java 内存模型的 happen before（先行先发） 原则，对volatile 字段的写入操作先于读操作，即使两个线程同时修改和获取 volatile 变量，get操作也能拿到最新的值。

扩容

扩容的时候首先会创建一个两倍于原容量的数组，然后将原数组里的元素进
行再 hash 后插入到新的数组里。为了高效 ConcurrentHashMap 不会对整个容器进行扩容，而只对某个 segment 进行扩容。

remove方法的实现

V remove(Object key, int hash, Object value) { 
            lock(); //加锁
            try{ 
                int c = count - 1; 
                HashEntry<K,V>[] tab = table; 
                //根据散列码找到 table 的下标值
                int index = hash & (tab.length - 1); 
                //找到散列码对应的那个桶
                HashEntry<K,V> first = tab[index]; 
                HashEntry<K,V> e = first; 
                while(e != null&& (e.hash != hash || !key.equals(e.key))) 
                    e = e.next; 

                V oldValue = null; 
                if(e != null) { 
                    V v = e.value; 
                    if(value == null|| value.equals(v)) { //找到要删除的节点
                        oldValue = v; 
                        ++modCount; 
                        //所有处于待删除节点之后的节点原样保留在链表中
                        //所有处于待删除节点之前的节点被克隆到新链表中
                        HashEntry<K,V> newFirst = e.next;// 待删节点的后继结点
                        for(HashEntry<K,V> p = first; p != e; p = p.next) 
                            newFirst = new HashEntry<K,V>(p.key, p.hash, 
                                                          newFirst, p.value); 
                        //把桶链接到新的头结点
                        //新的头结点是原链表中，删除节点之前的那个节点
                        tab[index] = newFirst; 
                        count = c;      //写 count 变量
                    } 
                } 
                return oldValue; 
            } finally{ 
                unlock(); //解锁
            } 
        }

整个操作是在持有段锁的情况下执行的，空白行之前的行主要是定位到要删除的节点e。接下来，如果不存在这个节点就直接返回null，**否则就要将e前面的结点复制一遍，**尾结点指向e的下一个结点。e后面的结点不需要复制，它们可以重用。

中间那个for循环是做什么用的呢？从代码来看，就是将定位之后的所有entry克隆并拼回前面去，但有必要吗？每次删除一个元素就要将那之前的元素克隆一遍？这点其实是由entry的不变性来决定的，仔细观察entry定义，发现除了value，其他所有属性都是用final来修饰的，这意味着在第一次设置了next域之后便不能再改变它，取而代之的是将它之前的节点全都克隆一次。至于entry为什么要设置为不变性，这跟不变性的访问不需要同步从而节省时间有关

执行删除之前的原链表：

执行删除之后的新链表

两次hash过程

第一次找到所在的桶，并将桶锁定（get操作不加锁），第二次执行写操作。而读操作不加锁

concurrenthashmap（对比hashtable，SynchronizeMap）的优化

• Collections.SynchronizedMap 和 Hashtable 都是整个表的锁，与 ConcurrentHashMap 锁粒度不同
• ConcurrentHashMap 不允许 key 或 value 为 null 值。
• ConcurrentHashMap 允许一边更新、一边遍历，也就是说在 Iterator 对象遍历的时候，ConcurrentHashMap 也可以进行 remove,put 操作，且遍历的数据会随着 remove,put 操作产出变化，相当于有多个线程在操作同一个 map（可以在 foreach keyset 时 remove 对象，HashMap 不可以）

ConcurrentHashMap 的高并发性主要来自于三个方面：

• 用分离锁实现多个线程间的更深层次的共享访问。减小了请求同一个锁的频率
• 用 HashEntery 对象的不变性来降低执行读操作的线程在遍历链表期间对加锁的需求。
• 通过对同一个 Volatile 变量的写 / 读访问，协调不同线程间读 / 写操作的内存可见性。

ConcurrentHashmap 和 Hashtable 不允许 key 和 value 为 null：

ConcurrentHashmap 和 Hashtable 都是支持并发的，这样会有一个问题，当你通过 get(k)获取对应的 value 时，如果获取到的是 null 时，你无法判断，它是 put（k,v）的时候 value为 null，还是这个 key 从来没有做过映射。HashMap 是非并发的，可以通过 contains(key)来做这个判断。而支持并发的 Map 在调用 m.contains（key）和 m.get(key),m 可能已经不同了。

Collections.synchronizedMap 和 HashMap 的 key 和 value 都可以为 null （因为就是包装了hashmap），TreeMap 的 key 不可为空（非线程安全，需要排序），value 可以