ConcurrentHashMap笔记

ConcurrrentHashMap的高并发性

主要是参考这一篇，权当学习笔记啦

谈到ConcurrentHashMap 由于涉及到高并发性，所以就不得不涉及到java的内存模型（不懂多线程内存模型，何谈并发？）

重排序：表现为一种乱序执行，编译器生成指令的次序，可以不同于源代码所写的顺序执行（即编译器有可能不是顺序执行）。重排序后的指令，对于优化执行以及成熟的全局寄存器分配算法的使用，都是大有脾益的，它使得程序在计算性能上有了很大的提升。

内存可见性（主内存与各个子内存的存取）：多核处理器中每个处理器都有自己的缓存，并发周期性的与主内存协调一致即满足了内存可见性。内存不可见场景：假设线程 A 写入一个变量值 V，随后另一个线程 B 读取变量 V 的值，在下列情况下，线程 B 读取的值可能不是线程 A 写入的最新值

先行发生原则：如果线程 A 与线程 B 满足 happens-before 关系，则线程 A 执行动作的结果对于线程 B 是可见的。（告一段落）

ConcurrentHashMap 在默认并发级别会创建包含16 个 Segment（Segment 用来充当锁的角色，每个 Segment 对象守护整个散列映射表的若干个桶） 对象的数组。每个 Segment 的成员对象 table 包含若干个散列表的桶。每个是由 HashEntry 链接起来的一个链表。如果键能均匀散列，每个 Segment 大约守护整个散列表中桶总数的 1/16。如图

在 ConcurrentHashMap 中，线程对映射表做读操作时，一般情况下不需要加锁就可以完成，（注意是一般，当get到的Value为空时，由于ConcurrentHashMap不允许用value=null,所以说明发生了重排序，此时需要加锁后重新读入）（Segment继承了ReetrantLock并不是读写分离锁，虽然有点读写分离锁的味道）,进行写操作时（put方法中），只针对相应的Segment加锁，并不对整个ConcurrentHashMap加锁，（此时Segment又有点分段锁的意思）

用 HashEntery 对象的不变性来降低读操作对加锁的需求

在代码清单“HashEntry 类的定义”中我们可以看到，HashEntry 中的 key，hash，next 都声明为 final 型。这意味着，不能把节点添加到链接的中间和尾部，也不能在链接的中间和尾部删除节点。这个特性可以保证：在访问某个节点时，这个节点之后的链接不会被改变。这个特性可以大大降低处理链表时的复杂性。

    读线程分析（同时存在写线程，读线程时，是否对读线程造成影响）：HashEntry 类的value 域被声明为 Volatile 型，Java 的内存模型可以保证：某个写线程对 value 域的写入马上可以被后续的某个读线程“看”到。在 ConcurrentHashMap 中，不允许用 unll 作为键和值，当读线程读到某个 HashEntry 的 value 域的值为 null 时，便知道产生了冲突（这个在前面已经提到）——发生了重排序现象，需要加锁后重新读入这个 value 值。这些特性互相配合，使得读线程即使在不加锁状态下，也能正确访问 ConcurrentHashMap。

写线程分析（同时存在写线程，读线程时，是否对读线程造成影响）：从两方面分析即对散列表做非结构性修改的操作和对散列表做结构性修改的操作。

非结构性修改：就是在更改某个 HashEntry 的 value 域的值。由于对 Volatile 变量的写入操作将与随后对这个变量的读操作进行同步。当一个写线程修改了某个 HashEntry 的 value 域后，另一个读线程读这个值域，Java 内存模型能够保证读线程读取的一定是更新后的值。所以，写线程对链表的非结构性修改能够被后续不加锁的读线程“看到”。

结构性修改： put，remove，clear三个操作

clear:clear 操作只是把 ConcurrentHashMap 中所有的桶“置空”，每个桶之前引用的链表依然存在，只是桶不再引用到这些链表（所有链表的结构并没有被修改）。正在遍历某个链表的读线程依然可以正常执行对该链表的遍历。

put:在 Segment 中执行具体的 put 操作中，源代码如下

V put(K key, int hash, V value, boolean onlyIfAbsent) {             lock();  // 加锁，这里是锁定某个 Segment 对象而非整个 ConcurrentHashMap             try {                 int c = count;                 if (c++ > threshold)     // 如果超过再散列的阈值                    rehash();              // 执行再散列，table 数组的长度将扩充一倍                HashEntry<K,V>[] tab = table;                 // 把散列码值与 table 数组的长度减 1 的值相“与”                // 得到该散列码对应的 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;                 if (e != null) {            // 如果键 / 值对以经存在                    oldValue = e.value;                     if (!onlyIfAbsent)                         e.value = value;    // 设置 value 值                }                 else {                        // 键 / 值对不存在                     oldValue = null;                     ++modCount;         // 要添加新节点到链表中，所以 modCont 要加 1                      // 创建新节点，并添加到链表的头部                     tab[index] = new HashEntry<K,V>(key, hash, first, value);                     count = c;               // 写 count 变量                }                 return oldValue;             } finally {                 unlock();                     // 解锁            }         }

我们可以看出：put 操作如果需要插入一个新节点到链表中时 , 会在链表头部插入这个新节点。此时，链表中的原有节点的链接并没有被修改。也就是说：插入新健 / 值对到链表中的操作不会影响读线程正常遍历这个链表。

remove:下面来分析 remove 操作，先让我们来看看 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();               // 解锁            }         }

和 get 操作一样，首先根据散列码找到具体的链表；然后遍历这个链表找到要删除的节点；最后把待删除节点之后的所有节点原样保留在新链表中，把待删除节点之前的每个节点克隆到新链表中。下面通过图例来说明 remove 操作。假设写线程执行 remove 操作，要删除链表的 C 节点，另一个读线程同时正在遍历这个链表。

图 4. 执行删除之前的原链表：

图 5. 执行删除之后的新链表

从上图可以看出，删除节点 C 之后的所有节点原样保留到新链表中；删除节点 C 之前的每个节点被克隆到新链表中，注意：它们在新链表中的链接顺序被反转了。

在执行 remove 操作时，原始链表并没有被修改，也就是说：读线程不会受同时执行 remove 操作的并发写线程的干扰。

综合上面的分析我们可以看出，写线程对某个链表的结构性修改不会影响其他的并发读线程对这个链表的遍历访问。

ConcurrentHashMap 实现高并发的总结

基于通常情形而优化

在实际的应用中，散列表一般的应用场景是：除了少数插入操作和删除操作外，绝大多数都是读取操作，而且读操作在大多数时候都是成功的。正是基于这个前提，ConcurrentHashMap 针对读操作做了大量的优化。通过 HashEntry 对象的不变性和用 volatile 型变量协调线程间的内存可见性，使得 大多数时候，读操作不需要加锁就可以正确获得值。这个特性使得 ConcurrentHashMap 的并发性能在分离锁的基础上又有了近一步的提高。

总结

ConcurrentHashMap 是一个并发散列映射表的实现，它允许完全并发的读取，并且支持给定数量的并发更新。相比于 HashTable 和用同步包装器包装的 HashMap（Collections.synchronizedMap(new HashMap())），ConcurrentHashMap 拥有更高的并发性。在 HashTable 和由同步包装器包装的 HashMap 中，使用一个全局的锁来同步不同线程间的并发访问。同一时间点，只能有一个线程持有锁，也就是说在同一时间点，只能有一个线程能访问容器。这虽然保证多线程间的安全并发访问，但同时也导致对容器的访问变成串行化的了。

在使用锁来协调多线程间并发访问的模式下，减小对锁的竞争可以有效提高并发性。有两种方式可以减小对锁的竞争：

1. 减小请求 同一个锁的 频率。
2. 减少持有锁的 时间。

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

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

使用分离锁，减小了请求 同一个锁的频率。

通过 HashEntery 对象的不变性及对同一个 Volatile 变量的读 / 写来协调内存可见性，使得 读操作大多数时候不需要加锁就能成功获取到需要的值。由于散列映射表在实际应用中大多数操作都是成功的 读操作，所以 2 和 3 既可以减少请求同一个锁的频率，也可以有效减少持有锁的时间。

通过减小请求同一个锁的频率和尽量减少持有锁的时间 ，使得 ConcurrentHashMap 的并发性相对于 HashTable 和用同步包装器包装的 HashMap有了质的提高。