CocurrentHashMap的应用及实现

本文详细解析了ConcurrentHashMap的工作原理及其与HashMap、HashTable的区别。重点介绍了ConcurrentHashMap的内部结构、锁分段技术以及get、put、size操作的具体实现。

首先常用三种HashMap包括HashMap,HashTable和CocurrentHashMap:

  • HashMap在并发编程过程中使用可能导致死循环,因为插入过程不是原子操作,每个HashEntry是一个链表节点,很可能在插入的过程中,已经设置了后节点,实际还未插入,最终反而插入在后节点之后,造成链中出现环,破坏了链表的性质,失去了尾节点,出现死循环。
  • HashTable因为内部是采用synchronized来保证线程安全的,但在线程竞争激烈的情况下HashTable的效率下降得很快因为synchronized关键字会造成代码块或方法成为为临界区(对同一个对象加互斥锁),当一个线程访问临界区的代码时,其他线程也访问同一临界区时,会进入阻塞或轮询状态。究其原因,实际上是有获取锁意向的线程的数目增加,但是锁还是只有单个,导致大量的线程处于轮询或阻塞,导致同一时间段有效执行的线程的增量远不及线程总体增量。 
    • 在查询时,尤其能够体现出CocurrentHashMap在效率上的优势,HashTable使用Sychronized关键字,会导致同时只能有一个查询在执行,而Cocurrent则不采取加锁的方法,而是采用volatile关键字,虽然也会牺牲效率,但是由于Sychronized,于该文末尾继续讨论。
  • CocurrentHashMap利用锁分段技术增加了锁的数目,从而使争夺同一把锁的线程的数目得到控制。 
    • 锁分段技术就是对数据集进行分段,每段竞争一把锁,不同数据段的数据不存在锁竞争,从而有效提高 高并发访问效率
    • CocurrentHashMap在get方法是无需加锁的,因为用到的共享变量都采用volatile关键字修饰,巴证共享变量在线程之间的可见性(每次读取都先同步缓存和内存,直接从内存中获取值,虽然不是原子操作,但根据JAVA内存模型的happen before原则,对volatile字段的写入操作先于读操作,能够保证不会脏读),volatile为了让变量提供线程之间的内存可见性,会禁止程序执行结果的重排序(导致缓存优化的效果降低)

CocurrentHashMap的结构

  • CocurrentHashMap是由Segment数组HashEntry数组组成。
  • Segment是重入锁(ReentrantLock),作为一个数据段竞争锁,每个HashEntry一个链表结构的元素,利用Hash算法得到索引确定归属的数据段,也就是对应到在修改时需要竞争获取的锁。

segments数组的初始化

  • 首先简单描述一下源代码中变量的含义:
变量名称描述
cocurrencyLevel能够满足的并发访问数量,即最多同时可以有多少线程同时访问一个CocurrencyHashMap对象(个人的理解)
ssizesegments数组的长度(因为要利用位运算和hash算法获取索引,故必须是),而且在确定长度时能够保证复杂度在
segmentShift散列后的32中的高位表示segments的索引,代表作无符号右移的偏移量
segmentMask对应与segment的ssize-1,有效的二进制位都为1,可以通过与散列后的数值与运算得到segment的索引
threshold一个segment的容量
initialCapacityCocurrentHashMap的初始化容量
cap一个segment中HashEntry数组的长度
loadFactor负载因子,我理解的是负载因子越大会导致出现冲突的概率增大,设置的过小又会浪费空间,所以应该根据实际情况考虑空间和时间上的平衡
  • 首先计算出segment数组的长度ssize,并且计算出与ssize关联的segmentShift和segmentMask
if ( cocurrencyLevel > MAX_SEGMENTS )
    cocurrencyLevel = MAX_SEGMENTS;
//如果cocurrencyLevel大于上限,那么取值为上限,
//上限定义为65535,决定了重入锁的segments的数目
int sshift = 0;
int ssize = 1;
//找到大于等于concurrencyLevel的最小的2^n作为segments的大小
while ( ssize < concurrencyLevel ){
    ++sshift;//记录偏移量,为了以后通过与运算获取segment的索引
    ssize <<=1;
}
segmentShift = 32 - sshift;//说明只有高sshift位作为segment的索引
segmentMask = ssize - 1;//能直接通过与运算获取segment的索引
this.segments = Segment.newArray(ssize);
//静态工厂方法构造ssize大小的segment数组
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 初始化每个segment,因为已经知道segment数组的规模,将ConcurrentHashMap的逻辑上持有的HashEntry均分到每个Segment上,因为是散列,所以要loadFactor来定义负载率,来保证segment适时的拓充,来避免散列表和数据规模相近时,冲突加重的风险。
if ( initialCapacity > MAXIMUM_CAPACITY )
    initialCapacity = MAXIMUM_CAPACITY;
int c = initCapacity / ssize;
//整个cocurrentHashMap的容量由所有的segment均摊
if ( c * ssize < initCapacity )
    ++c;
int cap = 1;//segment中的hashEntry数组的长度
while ( cap < c )
    cap <<= 1;
//设置loadFactor,保证散列的高效性的同时也保证空间浪费相对有限
for ( int i = 0 ; i < this.segments.length ; i++ )
    this.segments[i] =  new Segments<K,V>(cap , loadFactor);
//最终计算出segment的容量threshold=(int)cap*loadFactor;
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 定位segment,定位segment尤其重要,如果太多元素集中在少数几个segment中会导致CocurrentHashMap的效率得不到优化,因为同一个segment中的修改还是要竞争锁,所以选择合适的hash算法尽可能地将元素分到不同的segment中是目标。 
    • CocurrentHashMap采用的是对元素的HashCode进行再Hash来减少冲突
    • CocurrentHashMap采用的是根据Wang/JenkinsHash改进的hash算法,该算法具有雪崩性(参数一位数字变化,结果都有半数左右(二进制位)发生变化)
final Segment<K,V> segmentFor ( int hash ){
    //首先根据segmentShift无符号右移,得到表示segment所以的高位,
    //然后与掩码逻辑与得到segment的索引,定位到segment
    return segments[(hash>>>segmentShift)&segmentMask];
}
  • 1
  • 2
  • 3
  • 4
  • 5

CocurrentHashMap的操作

  • Segment的get操作是不需要加锁的。因为volatile修饰的变量保证了线程之间的可见性
  • Segment的put操作是需要加锁的,在插入时会先判断Segment里的HashEntry数组是否会超过容量(threshold),如果超过需要对数组扩容,翻一倍。然后在新的数组中重新hash,为了高效,CocurrentHashMap只会对需要扩容的单个Segment进行扩容
  • CocurrentHashMap获取size的时候要统计Segments中的HashEntry的和,如果不对他们都加锁的话,无法避免数据的修改造成的错误,但是如果都加锁的话,效率又很低。所以CoccurentHashMap在实现的时候,巧妙地利用了在累加过程中发生变化的几率很小的客观条件,在获取count时,不加锁的计算两次,如果两次不相同,在采用加锁的计算方法。采用了一个高效率的剪枝防止很大概率地减少了不必要额加锁。
  • 主要研究ConcurrentHashMap的3种操作——get操作、put操作和size操作.

    5.1 get操作

    Segment的get操作实现非常简单和高效. 
    - 先经过一次再散列 
    - 然后使用这个散列值通过散列运算定位到Segment 
    - 再通过散列算法定位到元素.

    public V get(Object key) {
        Segment<K,V> s; 
        HashEntry<K,V>[] tab;
        int h = hash(key);
    //找到segment的地址 long u = (((h >>> segmentShift) & segmentMask) << SSHIFT) + SBASE;
    //取出segment,并找到其hashtable if ((s = (Segment<K,V>)UNSAFE.getObjectVolatile(segments, u)) != null &&
            (tab = s.table) != null) {
    //遍历此链表,直到找到对应的值 for (HashEntry<K,V> e = (HashEntry<K,V>) UNSAFE.getObjectVolatile
                     (tab, ((long)(((tab.length - 1) & h)) << TSHIFT) + TBASE);
                 e != null; e = e.next) {
                K k;
                if ((k = e.key) == key || (e.hash == h && key.equals(k)))
                    return e.value;
            }
        }
        return null;
    }
    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    • 11
    • 12
    • 13
    • 14
    • 15
    • 16
    • 17

    整个get方法不需要加锁,只需要计算两次hash值,然后遍历一个单向链表(此链表长度平均小于2),因此get性能很高。 
    高效之处在于整个过程不需要加锁,除非读到的值是空才会加锁重读. 
    HashTable容器的get方法是需要加锁的,那ConcurrentHashMap的get操作是如何做到不加锁的呢? 
    原因是它的get方法将要使用的共享变量都定义成了volatile类型
    如用于统计当前Segement大小的count字段和用于存储值的HashEntry的value.定义成volatile的变量,能够在线程之间保持可见性,能够被多线程同时读,并且保证不会读到过期的值,但是只能被单线程写(有一种情况可以被多线程写,就是写入的值不依赖于原值), 
    在get操作里只需要读不需要写共享变量count和value,所以可以不用加锁. 
    之所以不会读到过期的值,是因为根据Java内存模型的happen before原则,对volatile字段的写操作先于读操作,即使两个线程同时修改和获取 
    volatile变量,get操作也能拿到最新的值, 

    这是用volatile替换锁的经典应用场景.

    transient volatile int count;
    volatile V value;
    • 1
    • 2

    在定位元素的代码里可以发现,定位HashEntry和定位Segment的散列算法虽然一样,都与数组的长度减去1再相“与”,但是相“与”的值不一样

    • 定位Segment使用的是元素的hashcode再散列后得到的值的高位
    • 定位HashEntry直接使用再散列后的值.

    其目的是避免两次散列后的值一样,虽然元素在Segment里散列开了,但是却没有在HashEntry里散列开.

    hash >>> segmentShift & segmentMask   // 定位Segment所使用的hash算法
    int index = hash & (tab.length - 1);   // 定位HashEntry所使用的hash算法
    • 1
    • 2

    5.2 put操作

    由于需要对共享变量进行写操作,所以为了线程安全,在操作共享变量时必须加锁
    put方法首先定位到Segment,然后在Segment里进行插入操作. 
    插入操作需要经历两个步骤

    • 判断是否需要对Segment里的HashEntry数组进行扩容
    • 定位添加元素的位置,然后将其放在HashEntry数组里

      1. 是否需要扩容 
        在插入元素前会先判断Segment里的HashEntry数组是否超过容量(threshold),如果超过阈值,则对数组进行扩容. 
        值得一提的是,Segment的扩容判断比HashMap更恰当,因为HashMap是在插入元素后判断元素是否已经到达容量的,如果到达了就进行扩容,但是很有可能扩容之后没有新元素插入,这时HashMap就进行了一次无效的扩容.
      2. 如何扩容 
        在扩容的时候,首先会创建一个容量是原来两倍的数组,然后将原数组里的元素进行再散列后插入到新的数组里. 
        为了高效,ConcurrentHashMap不会对整个容器进行扩容,而只对某个segment扩容.

    put方法的第一步,计算segment数组的索引,并找到该segment,然后调用该segment的put方法。

    public V put(K key, V value) {
        Segment<K,V> s;
        if (value == null)
            throw new NullPointerException();
        int hash = hash(key);
    //计算segment数组的索引,并找到该segment int j = (hash >>> segmentShift) & segmentMask;
        if ((s = (Segment<K,V>)UNSAFE.getObject          // nonvolatile; recheck
             (segments, (j << SSHIFT) + SBASE)) == null) //  in ensureSegment
            s = ensureSegment(j);
    //调用该segment的put方法 return s.put(key, hash, value, false);
    }
    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    • 11

    put方法第二步,在Segment的put方法中进行操作。

    final V put(K key, int hash, V value, boolean onlyIfAbsent) {
    //调用tryLock()尝试加锁,若失败则调用scanAndLockForPut进行加锁,同时寻找key相应的节点node
        HashEntry<K,V> node = tryLock() ? null :
            scanAndLockForPut(key, hash, value);
    //以下的代码都运行在加锁状态
        V oldValue;
        try {
            HashEntry<K,V>[] tab = table;
    //计算hash表的索引值,并取出HashEntry int index = (tab.length - 1) & hash;
            HashEntry<K,V> first = entryAt(tab, index);
    //遍历此链表 for (HashEntry<K,V> e = first;;) {
    //如果链表不为空,在链表中寻找对应的node,找到后进行赋值,并退出循环 if (e != null) {
                    K k;
                    if ((k = e.key) == key ||
                        (e.hash == hash && key.equals(k))) {
                        oldValue = e.value;
                        if (!onlyIfAbsent) {
                            e.value = value;
                            ++modCount;
                        }
                        break;
                    }
                    e = e.next;
                }
    //如果在链表中没有找到对应的node else {
    //如果scanAndLockForPut方法中已经返回的对应的node,则将其插入first之前 if (node != null)
                        node.setNext(first);
                    else //否则,new一个新的HashEntry
                        node = new HashEntry<K,V>(hash, key, value, first);
                    int c = count + 1;
    //测试是否需要自动扩容 if (c > threshold && tab.length < MAXIMUM_CAPACITY)
                        rehash(node);
                    else //设置node到Hash表的index索引处
                        setEntryAt(tab, index, node);
                    ++modCount;
                    count = c;
                    oldValue = null;
                    break;
                }
            }
        } finally {
            unlock();
        }
        return oldValue;
    }
    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    • 11
    • 12
    • 13
    • 14
    • 15
    • 16
    • 17
    • 18
    • 19
    • 20
    • 21
    • 22
    • 23
    • 24
    • 25
    • 26
    • 27
    • 28
    • 29
    • 30
    • 31
    • 32
    • 33
    • 34
    • 35
    • 36
    • 37
    • 38
    • 39
    • 40
    • 41
    • 42
    • 43
    • 44
    • 45

    5.3 size操作

    如果要统计整个ConcurrentHashMap里元素的大小,就必须统计所有Segment里元素的大小后求和. 
    Segment里的全局变量count是一个volatile变量,那在多线程场景下,是不是直接把所有Segment的count相加就可以得到整个ConcurrentHashMap大小了呢?不是的,虽然相加时可以获取每个Segment的count的最新值,但是可能累加前使用的count发生了变化,那么统计结果就不准了.所以,最安全的做法是在统计size的时候把所有Segment的put、remove和clean方法全部锁住,但是这种做法显然非常低效.

    因为在累加count操作过程中,之前累加过的count发生变化的几率非常小,所以 
    ConcurrentHashMap的做法是
    先尝试2次通过不锁住Segment的方式来统计各个Segment大小,如果统计的过程中,容器的count发生了变化,则再采用加锁的方式来统计所有Segment的大小.

    那么ConcurrentHashMap又是如何判断在统计的时候容器是否发生了变化呢? 
    使用modCount变量,在put、remove和clean方法里操作元素前都会将变量modCount进行加1,那么在统计size前后比较modCount是否发生变化,从而得知容器的大小是否发生变化.


一点理解

synchronized(其实感觉是可以被重入锁和Condition完全取代的)和volatile的取舍:

  • 首先的区别就在于是否是原子操作,也就是单一的不可分割的操作,在多线程中,原子操作能够保证不受到其他线程的影响
  • synchonized就实现了原子性操作,不同的线程互斥地进入临界代码区,而且是内存可见的,也就是每个线程进入临界区时,都是从内存中获取的值,不会因为缓存而出现脏读。
  • volatile实现了内存可见性,会将修改的值直接写入内容,并且注销掉之前对于该变量的缓存,而且禁止了指令的排序。是它不是原子操作!!
  • CurrentHashMap原理与应用(JDK7版本)
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值