什么是ConcurrentHashMap?不同JDK下ConcurrentHashMap的区别？

什么是ConcurrentHashMap?不同JDK下ConcurrentHashMap的区别？

   一、HashMap线程安全

   我们知道，在并发情况下，使用HashMap会有线程安全的问题，那么如何避免呢？

   想要避免Hashmap的线程安全问题有很多办法，比如改用HashTable或者Collections.synchronizedMap

   但是，这两者有着共同的问题：性能。无论读操作还是写操作，他们都会给整个集合加锁，导致同一时间的其他操作为之阻塞。

   在并发环境下，如何能够兼顾线程安全和运行效率呢？这时候ConcurrentHashmap就应运而生来。

    二、ConcurrentHashMap

    在 JDK1.7 的时候，ConcurrentHashMap 对整个桶数组进行了分割分段(Segment，分段锁)，每一把锁只锁容器其中一部分数据，多线程访问容器里不同数据段的数据，就不会存在锁竞争，提高并发访问率。

    简单来说：ConcurrentHashMap优势就是采用了[锁分段技术]，每一个Segment就好比自治区，读写操作高度自治，Segment之间互不影响。

    1.  Segment

    这里面涉及到一个比较关键的概念：Segment。

    Segment本身就相当于一个HashMap对象。同HashMap一样，Segment包含一个HashEntry数组，数组中的每一个HashEntry既是一个键值对，也是一个链表的头节点。

    单一的Segment结构如下：

   

   像这样的Segment对象，在ConcurrentHashMap集合中有2的N次方个，共同保存在一个名为segments的数组当中。 

   因此整个ConcurrentHashMap的结构如下：

  

   可以说，ConcurrentHashMap是一个二级哈希表。在一个总的哈希表下面，有若干个子哈希表。

   这样的二级结构，和数据库的水平拆分有些相似。

   2. ConcurrentHashMap并发读写的几种情形

   1）Case1： 不同Segment的并发写入   

   说明：不同Segment的写入是可以并发执行的。

   2）Case2： 同一Segment的一写一读

 

   说明：同一Segment的写和读是可以并发执行的。 

   3）Case3：同一Segment的并发写入

 

  说明：Segment的写入是需要上锁的，因此对同一Segment的并发写入会被阻塞。

  由此可见，ConcurrentHashMap当中每个Segment各自持有一把锁。在保证线程安全的同时降低了锁的粒度，让并发操作效率更高。

  3. ConcurrentHashMap读写的详细过程

  1）Get方法

•   为输入的Key做Hash运算，得到hash值。
•   通过hash值，定位到对应的Segment对象
•   再次通过hash值，定位到Segment当中数组的具体位置。

  2）Put方法

•   为输入的Key做Hash运算，得到hash值。
•   通过hash值，定位到对应的Segment对象
•   获取可重入锁
•   再次通过hash值，定位到Segment当中数组的具体位置。
•   插入或覆盖HashEntry对象。

  说明：从步骤可以看出，ConcurrentHashMap在读写时都需要二次定位。首先定位到Segment，之后定位到Segment内的具体数组下标。

  4. 调用size方法时，如何解决一致性问题？

  1）分析

  这个问题Key理解为：既然每一个Segment都各自加锁，那么在调用Size方法的时候，怎么解决一致性的问题呢？

  Size方法的目的是统计ConcurrentHashMap的总元素数量， 自然需要把各个Segment内部的元素数量汇总起来。

  但是，如果在统计Segment元素数量的过程中，已统计过的Segment瞬间插入新的元素，这时候该怎么办呢？如下图：

 

 

  ConcurrentHashMap的Size方法是一个嵌套循环，大体逻辑如下：

•   遍历所有的Segment。
•   把Segment的元素数量累加起来。
•   把Segment的修改次数累加起来。
•   判断所有Segment的总修改次数是否大于上一次的总修改次数。如果大于，说明统计过程中有修改，重新统计，尝试次数+1；如果不是。说明没有修改，统计结束。
•   如果尝试次数超过阈值，则对每一个Segment加锁，再重新统计。
•   再次判断所有Segment的总修改次数是否大于上一次的总修改次数。由于已经加锁，次数一定和上次相等。
•   释放锁，统计结束。

  官方源代码如下：

 1 public int size() {
 2     // Try a few times to get accurate count. On failure due to
 3    // continuous async changes in table, resort to locking.
 4    final Segment<K,V>[] segments = this.segments;
 5     int size;
 6     boolean overflow; // true if size overflows 32 bits
 7     long sum;         // sum of modCounts
 8     long last = 0L;   // previous sum
 9     int retries = -1; // first iteration isn't retry
10     try {
11         for (;;) {
12             if (retries++ == RETRIES_BEFORE_LOCK) {
13                 for (int j = 0; j < segments.length; ++j)
14                     ensureSegment(j).lock(); // force creation
15             }
16             sum = 0L;
17             size = 0;
18             overflow = false;
19             for (int j = 0; j < segments.length; ++j) {
20                 Segment<K,V> seg = segmentAt(segments, j);
21                 if (seg != null) {
22                     sum += seg.modCount;
23                     int c = seg.count;
24                     if (c < 0 || (size += c) < 0)
25                         overflow = true;
26                 }
27             }
28             if (sum == last)
29                 break;
30             last = sum;
31         }
32     } finally {
33         if (retries > RETRIES_BEFORE_LOCK) {
34             for (int j = 0; j < segments.length; ++j)
35                 segmentAt(segments, j).unlock();
36         }
37     }
38     return overflow ? Integer.MAX_VALUE : size;
39 }

  2）为什么这样设计呢？

  这种思想和乐观锁悲观锁的思想如出一辙。

  原因：为了尽量不锁住所有Segment，首先乐观地假设Size过程中不会有修改。当尝试一定次数，才无奈转为悲观锁，锁住所有Segment保证强一致性。

  三、注意事项

  1. 这里介绍的ConcurrentHashMap原理和代码，都是基于Java1.7的。在Java8中会有些许差别。

  到了 JDK1.8 的时候，ConcurrentHashMap 已经摒弃了 Segment 的概念，而是直接用 Node 数组+链表+红黑树的数据结构来实现，并发控制使用 synchronized 和 CAS 来操作。（JDK1.6 以后 synchronized 锁做了很多优化） 整个看起来就像是优化过且线程安全的 HashMap，虽然在 JDK1.8 中还能看到 Segment 的数据结构，但是已经简化了属性，只是为了兼容旧版本。

  2.  ConcurrentHashMap在对Key求Hash值的时候，为了实现Segment均匀分布，进行了两次Hash

  具体来说：为了实现Segment的均匀分布，采用了两次Hash的策略。首先，它使用了传统的Hash算法（比如将Key的hashCode取模），得到的结果称为哈希值。然后，它对这个哈希值再进行一次Hash操作，这个操作通常称为“再散列”（rehashing），目的是进一步增加哈希值的随机性，减少哈希碰撞的概率，从而提高并发性能。这样得到的最终哈希值用于确定Key在哪个Segment中的位置。

 

  参考资料：《程序员小灰》微信公众号