ConcurrentHashMap的介绍

ConcurrentHashMap的介绍

   一、HashMap线程安全

   我们知道，在并发情况下，使用HashMap会有线程安全的问题，那么如何避免呢？想要避免Hashmap的线程安全问题有很多办法，比如改用HashTable或者Collections.synchronizedMap

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

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

    二、ConcurrentHashMap

    ConcurrentHashMap 是由 Segment 数组结构和 HashEntry 数组结构组成。

    在 JDK1.7 的时候，ConcurrentHashMap将数据分为一段一段（这个“段”就是 Segment）的存储，然后给每一段数据配一把锁，当一个线程占用锁访问其中一个段数据时，其他段的数据也能被其他线程访问。因此，就不会存在锁竞争，提高并发访问率。

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

    java7 ConcurrentHashMap 存储结构：

    

    1.  Segment

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

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

    单一的Segment结构如下：

   

  

   Segment 继承了 ReentrantLock,所以 Segment 是一种可重入锁，扮演锁的角色。HashEntry 用于存储键值对数据。

1 static class Segment<K,V> extends ReentrantLock implements Serializable {
2   //...
3 }

 

     说明：一个 ConcurrentHashMap 里包含一个 Segment 数组，Segment 的个数一旦初始化就不能改变。 Segment 数组的大小默认是 16，也就是说默认可以同时支持 16 个线程并发写。

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

    因此整个ConcurrentHashMap的结构如下：

  

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

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

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

   Segment 的结构和 HashMap 类似，是一种数组和链表结构，一个 Segment 包含一个 HashEntry 数组，每个 HashEntry 是一个链表结构的元素，每个 Segment 守护着一个 HashEntry 数组里的元素，当对 HashEntry 数组的数据进行修改时，必须首先获得对应的 Segment 的锁。也就是说，对同一 Segment 的并发写入会被阻塞，不同 Segment 的写入是可以并发执行的。

   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中会有些许差别。

   Java8 ConcurrentHashMap存储结构：

   Java 8 几乎完全重写了 ConcurrentHashMap，代码量从原来 Java 7 中的 1000 多行，变成了现在的 6000 多行。

   ConcurrentHashMap 取消了 Segment 分段锁，采用 Node数组 + CAS + synchronized 来保证并发安全。数据结构跟 HashMap 1.8 的结构类似，数组+链表/红黑二叉树。Java 8 在链表长度超过一定阈值（8）时将链表（寻址时间复杂度为 O(N)）转换为红黑树（寻址时间复杂度为 O(log(N))）

   Java 8 中，锁粒度更细，synchronized 只锁定当前链表的头节点或红黑二叉树的根节点，这样只要 hash 不冲突，就不会产生并发，就不会影响其他 Node 的读写，效率大幅提升。 

   虽然在 JDK1.8 中还能看到 Segment 的数据结构，但是已经简化了属性，只是为了兼容旧版本。

   源码如下：

1     /**
2      * Stripped-down version of helper class used in previous version,
3      * declared for the sake of serialization compatibility
4      */
5     static class Segment<K,V> extends ReentrantLock implements Serializable {
6         private static final long serialVersionUID = 2249069246763182397L;
7         final float loadFactor;
8         Segment(float lf) { this.loadFactor = lf; }
9     }

   2. 两次Hash

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

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

 

  参考资料：

 《程序员小灰》微信公众号

   https://javaguide.cn/

posted @ 2024-03-07 17:23  欢乐豆123  阅读(16)  评论(0)  编辑  收藏  举报