深入理解JUC之ConcurrentHashMap(JDK1.8)

HashMap 应该是大家使用最多的Map下的具体实现类, 但他有一个缺点就是 线程不安全的,如果我们需要在多线程的情况下使用HashMap就需要自己加锁,效率不好.而如果使用HashTable ,因为HashTable是 表锁,性能极低.
Java为了解决这种情况,在JUC中为我们提供了ConcurrentHashMap. 在JDK1.8以前,ConcurrentHashMap 底层数据结构与对应的HashMap结构一样,使用的是 数组+链表.而ConcurrentHashMap使用的是分段锁.每一段table数组分段锁起来,这样在并发线程不在一段的情况下,就可以没有所竞争提高效率…
在这里插入图片描述

而在JDK1.8的时候,HashMap和ConcurrentHashMap 做出了非常大也是非常牛逼的调整,极大地增加了性能.
1.8的HashMap 底层数据结构改为了, 数组+链表+红黑树的结构. 当我们要存入数据的时候,要先经过寻址算法

key.hash & (table.leng - 1)  //table 是HashMap的数组的长度.

这个的结果其实相当于 key.hash % table.leng. 这是考虑到了效率的问题,因为我们的计算机是无法识别我们的取模运算的,而位运算不同,可以直接计算,所以使用位运算来提高 运算效率.
而通过寻址算法之后,随着数据量的增加, hash碰撞就是不可避免的一个问题.

一旦发生hash碰撞,那么我们就将发生碰撞的桶位的结构改变成链表.
当链表长度>=8.切table长度>=64的时候,这时候我们就会将满足阈值的链表进行树化.

ConcurrentHashMap的的数据结构与HashMap基本类似. JDK1.8的ConcurrentHashMap 为了线程安全 ,采用的是synchronized和CAS来解决的.同时用到了LongAdder类中的很多方法和思想.

在这里插入图片描述

写入操作

下面就以 ConcurrentHashMap的put() 方法来作为切入点,聊一下ConcurrentHashMap;
源码如下:

public V put(K key, V value) {
        return putVal(key, value, false);
    }

    /** Implementation for put and putIfAbsent */
    final V putVal(K key, V value, boolean onlyIfAbsent) {
    	//首先判断放入的key和value 不能为空
        if (key == null || value == null) throw new NullPointerException();
        //hash 是 key 的hashcode经过扰动函数之后的hash值.
        //扰动函数的话就是  将  h^(h>>>16)&HASH_BITS   h^(h>>>16)是为了让 hash的高16位也参与到寻址之中
        //而 &HASH_BITS 就是将 hash值去除 高位 符号位.变为正数
        int hash = spread(key.hashCode());
        int binCount = 0;
        for (Node<K,V>[] tab = table;;) {
            Node<K,V> f; int n, i, fh;
            //情况一:  具体解析在下面
            if (tab == null || (n = tab.length) == 0)
                tab = initTable();
            //情况二:
            else if ((f = tabAt(tab, i = (n - 1) & hash)) == null) {
                if (casTabAt(tab, i, null,
                             new Node<K,V>(hash, key, value, null)))
                    break;                   // no lock when adding to empty bin
            }
            //情况三:
            else if ((fh = f.hash) == MOVED)
                tab = helpTransfer(tab, f);
            //情况四:
            else {
                V oldVal = null;
                synchronized (f) {
                    if (tabAt(tab, i) == f) {
                        if (fh >= 0) {
                            binCount = 1;
                            for (Node<K,V> e = f;; ++binCount) {
                                K ek;
                                if (e.hash == hash &&
                                    ((ek = e.key) == key ||
                                     (ek != null && key.equals(ek)))) {
                                    oldVal = e.val;
                                    if (!onlyIfAbsent)
                                        e.val = value;
                                    break;
                                }
                                Node<K,V> pred = e;
                                if ((e = e.next) == null) {
                                    pred.next = new Node<K,V>(hash, key,
                                                              value, null);
                                    break;
                                }
                            }
                        }
                        else if (f instanceof TreeBin) {
                            Node<K,V> p;
                            binCount = 2;
                            if ((p = ((TreeBin<K,V>)f).putTreeVal(hash, key,
                                                           value)) != null) {
                                oldVal = p.val;
                                if (!onlyIfAbsent)
                                    p.val = value;
                            }
                        }
                    }
                }
                if (binCount != 0) {
                    if (binCount >= TREEIFY_THRESHOLD)
                        treeifyBin(tab, i);
                    if (oldVal != null)
                        return oldVal;
                    break;
                }
            }
        }
        addCount(1L, binCount);
        return null;
    }

我们将数据put入ConcurrentHashMap 主要有以下几种情况:
情况一:
放入的时候,table还没有进行初始化.(ConCurrentHashMap 和HashMap 的table数组都是懒加载,只有当第一次存入数据的时候才会进行初始化)…这时候就会先进行初始化.因为 ConCurrentHashMap 是多线程情况下使用的,所以初始化情况下也可能会有多个线程,这时候就会采用CAS方式 , 通过sizeCTL这个标识,来确保只有一个线程进入初始化.其他未进入初始化的线程被迫自旋,当扩容完毕后,退出自旋,再去进行本来要进行的操作. 而此时,sizeCTL 变为了 下次要扩容时的 扩容阈值.
源码如下:

 private final Node<K,V>[] initTable() {
        Node<K,V>[] tab; int sc;
        while ((tab = table) == null || tab.length == 0) {
        	//判断线程是否进入扩容
            if ((sc = sizeCtl) < 0)
                Thread.yield(); // lost initialization race; just spin
             //重点关注这个地方:
            else if (U.compareAndSwapInt(this, SIZECTL, sc, -1)) {
                try {
                    if ((tab = table) == null || tab.length == 0) {
                        int n = (sc > 0) ? sc : DEFAULT_CAPACITY;
                        @SuppressWarnings("unchecked")
                        Node<K,V>[] nt = (Node<K,V>[])new Node<?,?>[n];
                        table = tab = nt;
                        sc = n - (n >>> 2);
                    }
                } finally {
                    sizeCtl = sc;
                }
                break;
            }
        }
        return tab;
    }

情况二:
table数组已经初始化,但桶位头节点没有数据,直接put进去…这里也是采用的CAS方法,确保只能有一个线程放入头节点.
情况三:
table数组已经初始化,但是,key找到的桶位已经被表示未MOVED, 此时是因为有其他线程触发了 table扩容,造成的数据迁移,这时候就会先去帮着table扩容, 经过一些列操作之后回到现在的方法,然后进入情况四.
情况四:
table数组已经初始化,桶位头节点也有了数据,这时,为了保证数据安全… 对头节点进行加锁,synchronizd(头节点), 保证只有一个线程可以操作次头节点,而且其他线程在写操作时,如果不是操作此头节点, 也不会发生线程冲突.从而较分段锁 更提高了效率.

写入操作又分为了两种情况:

  1. 要写入的是链表 : 遍历现在已经存在的节点,找到next为null 的节点,插入其后. 然后判断是否达到树化阈值 .从而进行树化. 而这里也有一个与HashMap 不同的地方,就是 TreeBin 节点不只是维护红黑树,而且还维护了一个TreeNode节点组成的双向链表.
  2. 要写入的是红黑树 : 按照红黑树出入方法插入到相应位置.

读取操作

而在进行写操作的时候,同时还会有读操作进入当前map进行操作.
这个时候 如果没有发生线程冲突,也就是 读线程和写线程操作的不是同一头节点,那么将会相安无事.
如果操作的是同一头节点的话.
这个时候,如果要读取的节点和写入的节点不是一个的话,.那么 直接在双线链表中读取数据,如果是同一个节点的话,
那么 通过CAS 加 锁标识 来让 写操作进入挂起状态,等最后一个读操作结束操作的时候,唤起写操作重新进入写入操作.(此时的写入操作是阻塞在 重新整理平衡树的 操作之前,而放入数据已经放入成功,所以也不形象读取这个放入的数据)


扩容机制

ConcurrentHashMap 的扩容因子与HashMap不同 ,是被final关键字修饰的, 因此是不可改变的.,

    /**
     * The load factor for this table. Overrides of this value in
     * constructors affect only the initial table capacity.  The
     * actual floating point value isn't normally used -- it is
     * simpler to use expressions such as {@code n - (n >>> 2)} for
     * the associated resizing threshold.
     */
    private static final float LOAD_FACTOR = 0.75f;

而他扩容也是像HashMap一样, 容量翻倍,. 且table长度必须是2的次幂.
多线程在扩容的情况下, ConcurrentHashMap 是通过给每一个参与到扩容的线程分配一个步长的table 进行扩容,有点类似1.7中的ConcurrentHashMap的分段上锁,而数据迁移 也是像HashMap 一样, 通过重新 计算寻址,来将数据分为高位和低分 分开存放到相应的位置.
值的一提的地方就是.在每次putVal() 方法之后,都会进入addCount()方法,来检测是否需要进行扩容.而在这个方法中,使用到了LongAdder,

  • 我准备过两天写这个类,到时候连个链接过去,

源码如下:

private final void addCount(long x, int check) {
        CounterCell[] as; long b, s;
        if ((as = counterCells) != null ||
            !U.compareAndSwapLong(this, BASECOUNT, b = baseCount, s = b + x)) { 
            CounterCell a; long v; int m;
            boolean uncontended = true;
            if (as == null || (m = as.length - 1) < 0 ||
                (a = as[ThreadLocalRandom.getProbe() & m]) == null ||
                !(uncontended =
                  U.compareAndSwapLong(a, CELLVALUE, v = a.value, v + x))) {
                fullAddCount(x, uncontended);
                return;
            }
            if (check <= 1)
                return;
            s = sumCount();
        }
        //进入到扩容~
        if (check >= 0) {
            Node<K,V>[] tab, nt; int n, sc;
            while (s >= (long)(sc = sizeCtl) && (tab = table) != null &&
                   (n = tab.length) < MAXIMUM_CAPACITY) {
                int rs = resizeStamp(n);
                if (sc < 0) {
                    //条件一:(sc >>> RESIZE_STAMP_SHIFT) != rs
                    //      true->说明当前线程获取到的扩容唯一标识戳 非 本批次扩容
                    //      false->说明当前线程获取到的扩容唯一标识戳 是 本批次扩容
                    //条件二: JDK1.8 中有bug jira已经提出来了 其实想表达的是 =  sc == (rs << 16 ) + 1
                    //        true-> 表示扩容完毕,当前线程不需要再参与进来了
                    //        false->扩容还在进行中,当前线程可以参与
                    //条件三:JDK1.8 中有bug jira已经提出来了 其实想表达的是 = sc == (rs<<16) + MAX_RESIZERS
                    //        true-> 表示当前参与并发扩容的线程达到了最大值 65535 - 1
                    //        false->表示当前线程可以参与进来
                    //条件四:(nt = nextTable) == null
                    //        true->表示本次扩容结束
                    //        false->扩容正在进行中
                    if ((sc >>> RESIZE_STAMP_SHIFT) != rs || sc == rs + 1 ||
                        sc == rs + MAX_RESIZERS || (nt = nextTable) == null ||
                        transferIndex <= 0)
                        break;
                    if (U.compareAndSwapInt(this, SIZECTL, sc, sc + 1))
                        transfer(tab, nt);
                }
                else if (U.compareAndSwapInt(this, SIZECTL, sc,
                                             (rs << RESIZE_STAMP_SHIFT) + 2))
                    transfer(tab, null);
                s = sumCount();
            }
        }
    }

首先.,判断一下 Longadd 中的 cells 数组是否创建,也就是说 是否发生了线程竞争,如果竞争的话,就创建cells数组,然后进行数据叠加,到s中,也就是 table的 桶位个数
然后 记数完毕之后,进入扩容阶段:
用 s >= (long)(sc = sizeCtl) 这个条件来限制是否进入扩容 ,之前说过, 如果 table进行初始化了,那么sizeCtl存储的就是下次扩容的阈值, 如果s>= 阈值了,那么就要开始扩容了, rs 是记录的扩容标识戳,用来判断 不同线程扩容的是否是同一次扩容操作.
然后通过两个CAS操作,来限制 触发扩容线程和 协助扩容线程 去进行扩容操作.

以上.

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值