jdk1.8中ConcurrentHashMap的并发原理

最新推荐文章于 2024-10-11 09:36:34 发布
最新推荐文章于 2024-10-11 09:36:34 发布
阅读量1.8k 收藏 6
点赞数 1
分类专栏： juc并发包系列
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/justuseit/article/details/102521086
版权

ConcurrentHashMap的并发原理

我们都知道jdk1.8之前ConcurrentHashMap是采用分段锁的机制允许多线程并发操作一个ConcurrentHashMap的方式来提高并发的，它的主要思想是优化HashTable中全局锁，让锁更加细粒度来达到更高的并发度的。
但是JDK1.8里面的ConcurrentHashMap则完全不一样，它用到了CAS思想，使用的是乐观锁思想，乐观锁认为对于同一个数据的并发操作是不会发生修改，在更新数据时会采用尝试更新不断重试的方式更新数据。synchronized锁则只锁一个节点，这样大大提高了并发性能，而且ConcurrentHashMap的数据结构和HashMap是一样的，不了解HashMap的结构可以参考下面这篇文章：
https://blog.csdn.net/justuseit/article/details/102487264

JDK1.8中的ConcurrentHashMap中比HashMap多了一个重要属性sizeCtl，它是一个控制标识符，为0时，表示table还未初始化，为正数时表示初始化或下一次扩容的大小；而如果sizeCtl为-1，表示正在进行初始化操作；而为-N时，则表示有N-1个线程正在进行扩容。

我们只需要理解ConcurrentHashMap的put和get两个方法就能理解它的并发原理。

1、put方法

先看put方法代码：

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) {
        if (key == null || value == null) throw new NullPointerException();
        int hash = spread(key.hashCode());
        int binCount = 0;
        for (Node<K,V>[] tab = table;;) {
            Node<K,V> f; int n, i, fh; K fk; V fv;
            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)))
                    break;                   // no lock when adding to empty bin
            }
            else if ((fh = f.hash) == MOVED)
                tab = helpTransfer(tab, f);
            else if (onlyIfAbsent // check first node without acquiring lock
                     && fh == hash
                     && ((fk = f.key) == key || (fk != null && key.equals(fk)))
                     && (fv = f.val) != null)
                return fv;
            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);
                                    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;
                            }
                        }
                        else if (f instanceof ReservationNode)
                            throw new IllegalStateException("Recursive update");
                    }
                }
                if (binCount != 0) {
                    if (binCount >= TREEIFY_THRESHOLD)
                        treeifyBin(tab, i);
                    if (oldVal != null)
                        return oldVal;
                    break;
                }
            }
        }
        addCount(1L, binCount);
        return null;
    }

核心逻辑在putVal方法里面，这个方法大致逻辑如下：
1、检查key和value都不能为空，算出key的hash值
2、如果table还没有初始化，则初始化table。
3、根据hash值取出table里的首节点，如果为空，就把当前值构造成节点通过cas插入当前桶中。如果插入成功就退出循环，返回值；如果插入失败则进行下一轮循环。
4、hash值对应的桶节点不为空，并且节点的hash值为-1，表示正在扩容，那么当前线程就加入扩容队伍帮助扩容
5、如果hash值匹配到的节点的hash值和value都和当前要put进去的值相等，并且设置了onlyIfAbsent为真，就直接返回当前存在的value值
6、以上情况都不满足，则对当前节点加锁，执行put链表和二叉树的逻辑，这个和hashMap的逻辑就是差不多的。

我们再来看看初始化table的代码：

 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.compareAndSetInt(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;
    }

1、如果发现有其他线程在初始化，就让当前线程让出cpu，继续下一轮循环。
2、如果没有其他线程在初始化，就通过cas修改sizeCtl的值为-1，开始进行初始化操作。
这里通过线程让出cpu继续循环，不挂起当前线程，减少线程间切换，又通过CAS操作来修改控制变量sizeCtl，设置为-1，如果设置成功，就进入初始化逻辑块，如果设置失败线程又进入下一轮循环，下一轮循环进来发现sizeCtl小于零，主动让出CPU。

可以看出来这个方法里面大量使用了CAS操作，多个地方去掉了锁的使用，不让线程挂起，减少了线程上下文切换，因为一个线程上下文切换要消耗几万个cpu时钟周期，而一个CAS重试只需要几十个CPU时钟周期，即使CAS重试几十次都还是性能要好于线程切换的。

2、get方法

先上代码：

    public V get(Object key) {
        Node<K,V>[] tab; Node<K,V> e, p; int n, eh; K ek;
        int h = spread(key.hashCode());
        if ((tab = table) != null && (n = tab.length) > 0 &&
            (e = tabAt(tab, (n - 1) & h)) != null) {
            if ((eh = e.hash) == h) {
                if ((ek = e.key) == key || (ek != null && key.equals(ek)))
                    return e.val;
            }
            else if (eh < 0)
                return (p = e.find(h, key)) != null ? p.val : null;
            while ((e = e.next) != null) {
                if (e.hash == h &&
                    ((ek = e.key) == key || (ek != null && key.equals(ek))))
                    return e.val;
            }
        }
        return null;
    }

可以看到整个get分为三种情况：
1、获取到节点不为空，并且节点的hash值等于key的hash值，直接返回节点的val
2、获取到的节点不为空，但是头节点的hash值不等于key的hash值，并且节点是一个链表，就遍历链表，找到对应的数据
3、如果节点的hash值小于零，则节点是一个二叉树（也可能正在扩容），就从树中找到对应的值。
通看所有代码，整个过程都没有用到锁。
那么有些人可能会觉得奇怪这个get方法如何保证线程安全？
比如下面两种情况：
在这里插入图片描述

这个疑虑就不用当心了，因为val这个字段在node类里面是volatile的，也就是线程直接是可见的。

还有一种情况就是，如果读线程找到了hash值相同的节点，但是写线程直接remove了呢？
我们去看看remove方法：

public V remove(Object key) {
        return replaceNode(key, null, null);
    }

    /**
     * Implementation for the four public remove/replace methods:
     * Replaces node value with v, conditional upon match of cv if
     * non-null.  If resulting value is null, delete.
     */
    final V replaceNode(Object key, V value, Object cv) {
        int hash = spread(key.hashCode());
        for (Node<K,V>[] tab = table;;) {
            Node<K,V> f; int n, i, fh;
            if (tab == null || (n = tab.length) == 0 ||
                (f = tabAt(tab, i = (n - 1) & hash)) == null)
                break;
            else if ((fh = f.hash) == MOVED)
                tab = helpTransfer(tab, f);
            else {
                V oldVal = null;
                boolean validated = false;
                synchronized (f) {
                    if (tabAt(tab, i) == f) {
                        if (fh >= 0) {
                            validated = true;
                            for (Node<K,V> e = f, pred = null;;) {
                                K ek;
                                if (e.hash == hash &&
                                    ((ek = e.key) == key ||
                                     (ek != null && key.equals(ek)))) {
                                    V ev = e.val;
                                    if (cv == null || cv == ev ||
                                        (ev != null && cv.equals(ev))) {
                                        oldVal = ev;
                                        if (value != null)
                                            e.val = value;
                                        else if (pred != null)
                                            pred.next = e.next;
                                        else
                                            setTabAt(tab, i, e.next);
                                    }
                                    break;
                                }
                                pred = e;
                                if ((e = e.next) == null)
                                    break;
                            }
                        }
                        else if (f instanceof TreeBin) {
                            validated = true;
                            TreeBin<K,V> t = (TreeBin<K,V>)f;
                            TreeNode<K,V> r, p;
                            if ((r = t.root) != null &&
                                (p = r.findTreeNode(hash, key, null)) != null) {
                                V pv = p.val;
                                if (cv == null || cv == pv ||
                                    (pv != null && cv.equals(pv))) {
                                    oldVal = pv;
                                    if (value != null)
                                        p.val = value;
                                    else if (t.removeTreeNode(p))
                                        setTabAt(tab, i, untreeify(t.first));
                                }
                            }
                        }
                        else if (f instanceof ReservationNode)
                            throw new IllegalStateException("Recursive update");
                    }
                }
                if (validated) {
                    if (oldVal != null) {
                        if (value == null)
                            addCount(-1L, -1);
                        return oldVal;
                    }
                    break;
                }
            }
        }
        return null;
    }

这个方法有点儿长，核心代码情况下面：
在这里插入图片描述
其实remove方法是把原来节点的值给替换成null，然后再把这个节点的引用从链表中移除的。如果删除发生在return e.val这行代码之前，那么返回的val肯定是null。

从ConcurrentHashMap的源码中我们可以学到很多并发控制的优秀思想，我个人就总结两点：
（1）当其他线程需要修改，当前线程也需要修改时，可以循环CAS修改直到成功。
（2）当其他线程在修改，当前线程可以修改也可以不修改时，可以帮组其他线程修改，也可以让出cpu，循环等待。
这样可以减少很多线程上下文切换。

java-并发-ConcurrentHashMap高并发机制-jdk1.8
阿里Darker
07-23 1万+
JDK8的版本，与JDK6的版本有很大的差异。实现线程安全的思想也已经完全变了，它摒弃了Segment（锁段）的概念，而是启用了一种全新的方式实现,利用CAS算法。它沿用了与它同时期的HashMap版本的思想，底层依然由“数组”+链表+红黑树的方式思想，但是为了做到并发，又增加了很多辅助的类，例如TreeBin，Traverser等对象内部类。CAS算法实现无锁化的修改值的操作，他可以大大降低锁代
Java并发-ConcurrentHashMap（1.8）
qq_16375857的博客
12-12 277
java 1.8抛弃了原有的 Segment 分段锁，而采用了CAS + synchronized来保证并发安全性，也将 1.7 中存放数据的 HashEntry 改为 Node，但作用都是相同的。数据结构如下： 1.8put方法整体流程 1.首先利用 spread 方法对 key 的 hashcode 进行一次 hash 计算，由此来确定这个值在 table 中的位置； 2.如果当前 table 数组还未初始化，先将 table 数组进行初始化操作；如果这个位置是 null 的，那么使用 C..
并发容器之ConcurrentHashMap(JDK 1.8版本)
weixin_34032827的博客
05-06 514
1.ConcurrentHashmap简介 在使用HashMap时在多线程情况下扩容会出现CPU接近100%的情况，因为hashmap并不是线程安全的，通常我们可以使用在java体系中古老的hashtable类，该类基本上所有的方法都采用synchronized进行线程安全的控制，可想而知，在高并发的情况下，每次只有一个线程能够获取对象监视器锁，这样的并发性能的确不令人满意。另外一种方式通过Co...
Java 中 ConcurrentHashMap 的并发度
最新发布
Flying_Fish_roe的博客
10-11 802
ConcurrentHashMap 中的“并发度”（Concurrency Level）是指能够同时被修改的线程数量。并发度的主要目的是减少锁的争用，从而提高并发性能。在早期的 Java 版本中，ConcurrentHashMap 的内部实现是通过一个“分段锁”机制（Segment Locking）来实现的。这个机制将整个哈希表分为多个“Segment”，每个 Segment 都可以独立地进行加锁操作，因此多个线程可以同时对不同的 Segment 进行操作，而不会产生锁的竞争。
ConcurrentHashMap的实现原理(JDK1.7和JDK1.8)
jiaoyajieqianyi的博客
11-19 1011
http://youzhixueyuan.com/concurrenthashmap.html HashMap、CurrentHashMap 的实现原理基本都是BAT面试必考内容，阿里P8架构师谈：深入探讨HashMap的底层结构、原理、扩容机制深入谈过hashmap的实现原理以及在JDK 1.8的实现区别，今天主要谈CurrentHashMap的实现原理，以及在JDK1.7和1.8的区别。 ...
并发容器：ConcurrentHashMap（JDK1.8）
小识的博客
04-07 1171
JDK1.8源码 构造函数 public ConcurrentHashMap(int initialCapacity, float loadFactor, int concurrencyLevel) { if (!(loadFactor > 0.0f) || initialCapacity < 0 || concurrencyLevel <= 0) throw new IllegalArgumentExceptio.
ConcurrentHashMap在jdk1.7和jdk1.8中的不同；
热门推荐
qq_41884976的博客
04-26 4万+
原博客： https://www.cnblogs.com/lujiango/p/7580558.html http://www.importnew.com/28263.html CouncurrentHashMap 线程安全 一、CouncurrentHashMap<jdk1.7> 1、底层： （1）底层数据结构： <jdk1.7>：数组（Segment） + 数组（H...
并发编程系列：ConcurrentHashMap的实现原理(JDK1.7和JDK1.8)
fct2001140269的博客
11-24 354
HashMap、CurrentHashMap 的实现原理基本都是BAT面试必考内容，阿里P8架构师谈：深入探讨HashMap的底层结构、原理、扩容机制深入谈过hashmap的实现原理，今天主要谈CurrentHashMap的实现原理。 内容目录： 1.哈希表 2.ConcurrentHashMap与HashMap、HashTable的区别 3.CurrentHashMap在JDK1.7和JDK1...
jdk1.8中ConcurrentHashMap的实现原理
Summer_YuXia的博客
05-01 1218
并发环境下为什么使用ConcurrentHashMap 1. HashMap在高并发的环境下，执行put操作会导致HashMap的Entry链表形成环形数据结构，从而导致Entry的next节点始终不为空，因此产生死循环获取Entry 2. HashTable虽然是线程安全的，但是效率低下，当一个线程访问HashTable的同步方法时，其他线程如果也访问HashTable的同步方法，那
JDK1.8中ConcurrentHashMap中computeIfAbsent死循环bug问题
08-24
JDK1.8中ConcurrentHashMap中computeIfAbsent死循环bug问题 JDK1.8中ConcurrentHashMap中computeIfAbsent方法是一个非常重要的方法，它可以让开发者在键不存在时，提供一个默认值作为回应。但是，在JDK1.8中，这个...
关于jdk1.8中ConcurrentHashMap
一叶一菩提的博客
09-23 1193
1.前言 Java JDK升级到1.8后有些集合类的实现有了变化， 其中ConcurrentHashMap就有进行结构上的大调整。 jdk1.6、1.7实现的我不会想了解去百度吧 2. 重要概念 想要了解ConcurrentHashMap 你至少要对HashMap有一定的了解吧？ HashMap（1.8）和ConcurrentHashMap（1.8） 底层都是hash表+链表+红黑树 如果对红黑树不了解的可以查看https://blog.csdn.net/A980719/article/details/12
JDK1.8的ConcurrentHashMap 的put、get 工作原理
weixin_44683593的博客
07-02 1760
JDK1.8的ConcurrentHashMap put总结： 如果没有初始化就先调用initTable（）方法来进行初始化过程 如果没有hash冲突就直接CAS插入 如果还在进行扩容操作就先进行扩容 如果存在hash冲突，就加锁来保证线程安全，这里有两种情况，一种是链表形式就直接遍历到尾端插入，一种是红黑树就按照红黑树结构插入， 如果Hash冲突时会形成Node链表，在链表长度超过8，Node数组超过64时会将链表结构转换为红黑树的结构，break再一次进入循环 如果添加成功就调用addCo
并发（）——ConcurrentHashMap 源码解析
想当厨子的程序媛
02-21 517
HashMap、HashTable与ConcurrentHashMap的区别 HashMap是线程不安全的。 HashTable是线程安全的。HashTable的线程安全是采用在每个方法上面都添加上了 synchronized 关键字来修饰，即 Hashtable 是针对整个 table　的锁定。所有访问 HashTable 的线程都必须竞争同一把锁。当一个线程访问 HashTable 的...
JDK1.8对ConcurrentHashMap的优化
zhoushimiao1990的博客
06-18 4008
ConcurrentHashMap在1.8中的优化： 取消segments字段，直接采用transient volatile HashEntry<K,V>[] table保存数据，采用table数组元素作为锁，从而实现了对每一行数据进行加锁，进一步减少并发冲突的概率。 将原先table数组＋单向链表的数据结构，变更为table数组＋单向链表＋红黑树的结构。对于hash表来说，最核心...
【Java并发】-- ConcurrentHashMap如何实现高效地线程安全（jdk1.8）
十年磨一剑，沉淀……
07-21 2707
1.传统集合框架并发编程中Map存在的问题？ 2.早期改进策略 HashTable HashTable相比HashMap是线程安全的，因为HashTable所有的方法都是加了synchronized的，锁的是整个hashMap，也就是我们说的锁的粒度比较大，由于最基本的put,set操作都加了互斥锁，造成的结果就是同一时间点只能由一个线程put或只能get，并发操作时所有的put,get操作都...
Java篇 - 并发容器之ConcurrentHashMap为何如此优秀? (基于JDK1.8)
u014294681的博客
12-28 348
Java并发容器类之ConcurrentHashMap为什么如此优秀？ HashMap是非线程同步的散列表，实现原理和HashTable类似，具体可以看我的这篇文章：《Java篇 - 并发容器类之Hashtable源码分析》https://blog.csdn.net/u014294681/article/details/85298342 HashTable不允许空key和空value，但是Ha...
JDK1.8中ConcurrentHashMap中computeIfAbsent死循环bug.docx
06-26
在JDK 1.8版本中，`ConcurrentHashMap`中的`computeIfAbsent`方法存在一个潜在的死循环问题。这个bug主要出现在并发操作时，当`ConcurrentHashMap`需要进行扩容并且`computeIfAbsent`正在执行计算的过程中，可能会...
ConcurrentHashMap实现高并发原理
weixin_33826268的博客
02-08 73
集合是编程中最常用的数据结构。而谈到并发，几乎总是离不开集合这类高级数据结构的支持。比如两个线程需要同时访问一个中间临界区（Queue），比如常会用缓存作为外部文件的副本（HashMap）。这篇文章主要分析jdk1.5的3种并发集合类型（concurrent，copyonright，queue）中的ConcurrentHashMap，让我们从原理上细致的了解它们，能够让我们在...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值
>