ConcurrentHashMap原理

        相信大家在面试的时候经常被问到类似问题:“实现HashMap线程安全的办法有哪些”“jdk1.7和jdk1.8在HashMap上面有什么区别?”“ConcurrentHashMap底层是怎么保证线程安全的”……当面试官问到HashMap的线程安全问题的时候大概率是想让你往ConcurretHashMap方向回答了(别问,问就是我已经被击穿几次了)。

一、什么是ConcurrentHashMap(对比版)?

 HashMap HashMap是线程不安全的,因为HashMap中操作都没有加锁,因此在多线程环境下会导致数据覆盖之类的问题,所以,在多线程中使用HashMap是会抛出异常的。

HashTable HashTable是线程安全的,但是HashTable只是单纯的在put()方法上加上synchronized。保证插入时阻塞其他线程的插入操作。虽然安全,但因为设计简单,所以性能低下。 

ConcurrentHashMap ConcurrentHashMap是线程安全的,ConcurrentHashMap并非锁住整个方法,而是通过原子操作和局部加锁的方法保证了多线程的线程安全,且尽可能减少了性能损耗。

发现没有,HashTable是不是好像没啥子用……

二、原理解析(附带源码)

ConcurrentHashMap 是 Java 中提供的一个线程安全的哈希表,它通过分段锁和 CAS(Compare-And-Swap)操作等技术来实现高并发和线程安全。以下是 ConcurrentHashMap 的一些核心原理和源码分析:

1. 分段锁机制(Java 8 之前)

在 Java 8 之前,ConcurrentHashMap 使用分段锁(Segmentation Lock)机制来实现并发控制。这种设计使得它能够在高并发环境下提供良好的性能。

  • 内部结构与初始化ConcurrentHashMap 内部主要由一个 Segment 数组、哈希函数和键值对节点构成。其中,Segment 是一个可重入的互斥锁,每个 Segment 包含一个哈希表,哈希表中的每个元素都是一个链表。

  • Segment 类Segment 类是 ConcurrentHashMap 实现并发控制的核心。它继承自 ReentrantLock,拥有自己的锁,并且包含一个哈希表。Segment 类中的哈希表结构与普通的 HashMap 类似,采用链表解决哈希冲突。

2. Java 8 中的 ConcurrentHashMap

从 Java 8 开始,ConcurrentHashMap 的实现发生了重大变化,摒弃了分段锁机制,转而使用 CAS 操作和 synchronized 来保证线程安全。

  • 数据结构ConcurrentHashMap 内部使用一个 Node 数组来存储键值对。Node 是一个静态内部类,包含键、值、哈希值和指向下一个节点的引用。

  • 链表与红黑树:当链表长度超过一定阈值(默认为 8)时,链表会被转换成红黑树,以提高搜索效率。

  • 扩容机制:在进行 put 操作时,如果检测到需要扩容,则会进行一次转移操作,将旧数组中的元素迁移到新数组中。

  • CAS 操作ConcurrentHashMap 使用 UNSAFE 类的 CAS 方法来实现无锁的原子操作,比如 compareAndSwapObjectgetObjectVolatile 等。

3. 源码分析

以下是一些关键的源码片段和它们的解释:

JDK1.7:

  • ensureSegment 方法:这个方法用于确保给定索引处的 Segment 存在,如果不存在,则创建它。这里使用了 CAS 操作来保证在多线程环境下 Segment 的创建是线程安全的。
@SuppressWarnings("unchecked")
private Segment<K,V> ensureSegment(int k) {
    final Segment<K,V>[] ss = this.segments;
    long u = (k << SSHIFT) + SBASE; // raw offset
    Segment<K,V> seg;
    if ((seg = (Segment<K,V>)UNSAFE.getObjectVolatile(ss, u)) == null) {
        // ...省略部分代码...
        while ((seg = (Segment<K,V>)UNSAFE.getObjectVolatile(ss, u)) == null) {
            if (UNSAFE.compareAndSwapObject(ss, u, null, seg = s)) {
                break;
            }
        }
    }
    return seg;
}

 重点:JDK1.8

在 JDK 1.8 中,ConcurrentHashMap 的实现相较于之前的版本有了很大的变化,它摒弃了分段锁(Segment)的概念,而是采用了 CAS(Compare-And-Swap)操作和 synchronized 来保证线程安全。

1. 存储结构

JDK 1.8 的 ConcurrentHashMap 存储结构由“数组+链表+红黑树”组成。当冲突链表达到一定长度时,链表会转换成红黑树,以提高搜索效率。

2. 初始化 initTable

ConcurrentHashMap 的初始化是通过自旋和 CAS 操作完成的。sizeCtl 变量的值决定着当前的初始化状态:

  • -1 表示正在初始化,其他线程需要自旋等待。
  • -N 表示 table 正在进行扩容,高 16 位表示扩容的标识戳,低 16 位减 1 为正在进行扩容的线程数。
  • 0 表示 table 初始化大小,如果 table 没有初始化。
  • >0 表示 table 扩容的阈值,如果 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.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;
}

3. put 操作

put 方法是 ConcurrentHashMap 中执行插入操作的核心方法。它首先计算键的哈希值,然后找到对应的 Node 或 TreeNode,并执行插入操作。如果链表长度超过一定阈值(默认为 8),则会将链表转换成红黑树。

final V putVal(int hash, K key, V value, boolean onlyIfAbsent,
boolean evict) {
    Node<K,V>[] tab; Node<K,V> p; int n, i;
    if ((tab = table) == null || (n = tab.length) == 0)
        n = (tab = resize()).length;
    if ((p = tab[i = (n - 1) & hash]) == null)
        tab[i] = newNode(hash, key, value, null);
    else {
        Node<K,V> e; K k;
        if (p.hash == hash &&
            ((k = p.key) == key || (key != null && key.equals(k))))
            e = p;
        else if (p instanceof TreeNode)
            e = ((TreeNode<K,V>)p).putTreeVal(this, tab, hash, key, value);
        else {
            for (int binCount = 0; ; ++binCount) {
                if ((e = p.next) == null) {
                    p.next = newNode(hash, key, value, null);
                    if (binCount >= TREEIFY_THRESHOLD - 1)
                        treeifyBin(tab, hash);
                    break;
                }
                if (e.hash == hash &&
                    ((k = e.key) == key || (key != null && key.equals(k))))
                    break;
                p = e;
            }
        }
        if (e != null) {
            V oldValue = e.val;
            if (!onlyIfAbsent || oldValue == null)
                e.val = value;
            afterNodeAccess(e);
            return oldValue;
        }
    }
    ++modCount;
    if (++size > threshold)
        resize();
    afterNodeInsertion(evict);
    return null;
}

4. 扩容机制

ConcurrentHashMap 在需要扩容时,会创建一个新的 Node 数组,并把旧数组中的元素迁移到新数组中。这个过程是并发安全的,使用了 ForwardingNode 来帮助迁移。

四、对比

这时候就有小伙伴问了:欸那为哈你介绍JDK1.8的ConcurrentHashMap这么详细,是不是偏心啊。那就总结一下JDK1.7和JDK1.8在这方面的区别吧!

JDK 1.7 和 JDK 1.8 中的 ConcurrentHashMap 在实现上的主要区别如下:

  1. 锁机制的变化

    • JDK 1.7:使用分段锁(Segment)机制,每个分段是一个 ReentrantLock,整个 ConcurrentHashMap 被划分为多个段,每个段内部使用一个锁来同步。这种设计限制了并发度,因为每个段的锁是独立的,但段内操作是互斥的。
    • JDK 1.8:摒弃了分段锁,转而使用 CAS(Compare-And-Swap)操作和 synchronized 来保证线程安全。这种设计提供了更细粒度的锁,可以锁住单个桶(Node),从而提高并发度。
  2. 数据结构的变化

    • JDK 1.7:由 Segment 数组 + HashEntry 数组 + 链表组成,每个 Segment 是一个独立的小哈希表,包含若干个桶,桶之间通过链表解决哈希冲突。
    • JDK 1.8:结构变为 Node 数组 + 链表 / 红黑树。当链表长度超过一定阈值(默认为 8)时,会将链表转换成红黑树,以提高搜索效率。
  3. 扩容机制的变化

    • JDK 1.7:扩容时会对整个 Segment 加锁,导致在高并发场景下性能下降。
    • JDK 1.8:扩容是从数组队尾开始拷贝,拷贝槽点时会锁住槽点,拷贝完成后将槽点设置为转移节点(ForwardingNode)。所以槽点拷贝完成后将新数组赋值给容器,支持多个线程同时扩容。
  4. 性能和并发性的提升

    • JDK 1.8:由于采用了更细粒度的锁和无锁的CAS操作,性能和并发性相较于 JDK 1.7 有了显著提升。
  5. 读写操作的优化

    • JDK 1.8:支持读写分离,多个线程可以同时进行读取操作而不会阻塞写入操作,这种设计极大地提升了并发性能。
  6. CAS操作的应用

    • JDK 1.8:在 ConcurrentHashMap 中广泛使用了CAS操作来替换哈希表中的键值对,这是一种原子操作,可以保证操作的原子性和一致性。
  7. 红黑树的引入

    • JDK 1.8:在链表长度超过阈值时,会将链表转换为红黑树,以保持高效的查找性能。

        这些改进使得 JDK 1.8 中的 ConcurrentHashMap 在处理高并发场景时,相较于 JDK 1.7 版本,提供了更好的性能和扩展性。所以我们当然是用好的啦!

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值