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 方法来实现无锁的原子操作，比如 compareAndSwapObject 和 getObjectVolatile 等。

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 版本，提供了更好的性能和扩展性。所以我们当然是用好的啦！