• ConcurrentHashMap源码分析


    1.ConcurrentHashMap原理介绍(JDK1.7)

    我们知道HashTable在并发情况下效率低的原因是所有访问HashTable的线程都必须竞争同一把锁,这就导致一旦一个线程获取了锁,其余所有的线程都必须处于等待状态。而ConcurrentHashMap使用的是锁分段技术,就是将数据分为一段一段的存储,给每一段数据都配一把锁,当一个线程占用一把锁访问其中一段数据的时候,其他段的数据也能够被其他线程访问。ConcurrentHashMap是由segment数组构成,segment是一个可重入锁,它的结构和HashMap类似,底层是一个HashEntry数组,看如下图:

    2.构造函数

     @SuppressWarnings("unchecked")
        public ConcurrentHashMap(int initialCapacity,
                                 float loadFactor, int concurrencyLevel) {
            if (!(loadFactor > 0) || initialCapacity < 0 || concurrencyLevel <= 0)
                throw new IllegalArgumentException();
            if (concurrencyLevel > MAX_SEGMENTS)
                concurrencyLevel = MAX_SEGMENTS;
            // Find power-of-two sizes best matching arguments
            int sshift = 0;
            int ssize = 1;
            while (ssize < concurrencyLevel) {
                ++sshift;
                ssize <<= 1;
            }
            this.segmentShift = 32 - sshift;
            this.segmentMask = ssize - 1;
            if (initialCapacity > MAXIMUM_CAPACITY)
                initialCapacity = MAXIMUM_CAPACITY;
    //initialCapacity是ConcurrentHashMap的初始化容量
    int c = initialCapacity / ssize; if (c * ssize < initialCapacity) ++c;
    // cap是每个segment的容量,也就是HashEntry数组的长度,它也是一个2的N次幂值
    int cap = MIN_SEGMENT_TABLE_CAPACITY; while (cap < c) cap <<= 1; // create segments and segments[0]
    // loadFactor是每个segment的负载因子,创建Segments数组,然后初始化每个Segment的值
    Segment<K,V> s0 = new Segment<K,V>(loadFactor, (int)(cap * loadFactor), (HashEntry<K,V>[])new HashEntry[cap]); Segment<K,V>[] ss = (Segment<K,V>[])new Segment[ssize]; UNSAFE.putOrderedObject(ss, SBASE, s0); // ordered write of segments[0] this.segments = ss; }

    通过以上代码可知:Segment的数组长度ssize是由concurrencyLevel计算出来的,ssize是一个大于等于concurrencyLevel的最小的2的N次幂值。sshift等于ssize从1向左移位的次数,默认情况下会移动4次,即sshift等于4。segmentShift和segmentMask在定位segment的算法中有使用到。

    3 方法

    3.1 get方法

     public V get(Object key) {
            Segment<K,V> s; // manually integrate access methods to reduce overhead
            HashEntry<K,V>[] tab;
    // 根据key的hash值h,以及之前得到的segmentShift,segmentMask等值得到u,从而定位到segment
    int h = hash(key); long u = (((h >>> segmentShift) & segmentMask) << SSHIFT) + SBASE; if ((s = (Segment<K,V>)UNSAFE.getObjectVolatile(segments, u)) != null && (tab = s.table) != null) {
    // 在定位到Segment后,然后定位到HashEntry数组中的位置,最后通过逐一比较,返回要找的值
    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; }

    有两个问题值得思考:一是在上面代码中,使用了UNSAFE.getObjectVolatile(segments, u)来获取segment,为什么不直接使用segments[u]来获取呢?我们知道每个线程都有自己的工作内存,里面存放着segments的副本,在并发环境下,并不能保证每次拿到的是segments中的最新元素。但是使用UNSAFE.getObjectVolatile(segments, u)可以直接获取指定内存的数据,保证拿到的数据是最新的。二是读操作为什么不需要加锁?get方法的高效之处就是不加锁,我们知道HashTable读操作时需要加锁的,那么ConcurrentHashMap是怎么做到的呢?HashEntry中的value值被定义为了volatile类型,这样value就能在多个线程间保持可见性,能够被多个线程读,而不会读到过期的值。一旦有线程修改value值,那么其他线程本地内存中的value值就会失效,从而保证去获取最新的value值,这是volatile代替锁的经典应用场景。

    3.2 put方法

        @SuppressWarnings("unchecked")
        public V put(K key, V value) {
            Segment<K,V> s;
            if (value == null)
                throw new NullPointerException();
    // 先根据key,segmentShift,segmentMask定位到segment
    int hash = hash(key); int j = (hash >>> segmentShift) & segmentMask; if ((s = (Segment<K,V>)UNSAFE.getObject // nonvolatile; recheck (segments, (j << SSHIFT) + SBASE)) == null) // in ensureSegment s = ensureSegment(j);
    // 然后,将key和value放到segment中 进入该方法
    return s.put(key, hash, value, false); }
     final V put(K key, int hash, V value, boolean onlyIfAbsent) {
    // put操作需要加锁 HashEntry
    <K,V> node = tryLock() ? null : scanAndLockForPut(key, hash, value); V oldValue; try { HashEntry<K,V>[] tab = table; int index = (tab.length - 1) & hash; HashEntry<K,V> first = entryAt(tab, index); for (HashEntry<K,V> e = first;;) { 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; } else { if (node != null) node.setNext(first); else node = new HashEntry<K,V>(hash, key, value, first); int c = count + 1;
    // 满足条件,则进行扩容操作
    if (c > threshold && tab.length < MAXIMUM_CAPACITY) rehash(node); else setEntryAt(tab, index, node); ++modCount; count = c; oldValue = null; break; } } } finally {
    // 解锁 unlock(); }
    return oldValue; }

    在put方法中,需要注意的是扩容时,针对的是某个segment,而不是对整个容器扩容。

    3.3 size方法

        public int size() {
            // Try a few times to get accurate count. On failure due to
            // continuous async changes in table, resort to locking.
            final Segment<K,V>[] segments = this.segments;
            int size;
            boolean overflow; // true if size overflows 32 bits
            long sum;         // sum of modCounts
            long last = 0L;   // previous sum
            int retries = -1; // first iteration isn't retry
            try {
                for (;;) {
    // 在尝试三次后,则加锁
    if (retries++ == RETRIES_BEFORE_LOCK) { for (int j = 0; j < segments.length; ++j) ensureSegment(j).lock(); // force creation } sum = 0L; size = 0; overflow = false; for (int j = 0; j < segments.length; ++j) { Segment<K,V> seg = segmentAt(segments, j); if (seg != null) { sum += seg.modCount; int c = seg.count; if (c < 0 || (size += c) < 0) overflow = true; } }
    // 如果在累加count前后,modCount不变,则跳出循环
    if (sum == last) break; last = sum; } } finally {
    // 尝试三次后,需要解锁
    if (retries > RETRIES_BEFORE_LOCK) { for (int j = 0; j < segments.length; ++j) segmentAt(segments, j).unlock(); } } return overflow ? Integer.MAX_VALUE : size; }

    对于获取ConcurrentHashMap中元素的个数,就是把每个segment中count的个数相加即可,但是这里有个问题,在多线程环境下,在累加count的过程中,之前已经累加过的count可能会发生变化,使用加锁处理的话能解决这个问题,但是在累加count操作过程中,之前累加过的count发生变化的几率非常小,那么ConcurrentHashMap是这样解决的:先尝试三次不加锁的方式来累加count,在累加结束前后比较modCount的值是否发生变化;如果发生变化,则再通过加锁的方式来统计累加count。

    最后关于ConcurrentHashMap,还有个问题:它的迭代器是强一致性的迭代器还是弱一致性的迭代器?在java.util包中集合类都返回fail-fast迭代器,这就意味着,在集合迭代过程中,如果修改集合内容,则会抛出异常ConcurrentModificationException,这是强一致性迭代器。但是在java.util.concurrent 集合返回的迭代器,是弱一致性迭代器,在遍历过程中,如果已经遍历的集合上的内容变化了,迭代器不会抛出ConcurrentModificationException异常。如果未遍历的数组上的内容发生了变化,则有可能反映到迭代过程中。这就是ConcurrentHashMap迭代器弱一致的表现,这是为了提升效率,是一致性与效率之间的一种权衡。

  • 相关阅读:
    各种页的意义
    ecstore Fatal error: Class 'base_request' not found
    viewer.js 视图预览demo
    div在另一个div居中对齐
    文件权限解释rwx
    TPshop各个目录模块介绍
    tpshop linux安装下注意事项
    navicate 远程无法链接linux上mysql数据库问题
    关于破解邮箱的一点心得
    linux开启新端口
  • 原文地址:https://www.cnblogs.com/51life/p/10126942.html
Copyright © 2020-2023  润新知