Java并发之ConcurrentHashMap

JDK 1.7

在JDK 1.7中，ConcurrentHashMap 使用了一种称为分段锁的机制。这种机制的核心思想是将哈希表分成多个段（Segment），默认16个，每个段实际上是一个独立的哈希表，并拥有自己的锁。

在put方法中，先通过ensureSegment方法定位到当前key存放的Segment，然后在调用Segment中的put方法。

    public V put(K key, V value) {
        Segment<K,V> s;
        if (value == null)
            throw new NullPointerException();
        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);
        return s.put(key, hash, value, false);
    }

Segment内部存储了HashEntry<K,V>类型的数组，Segment相当于一个HashMap。

这里的Segment为了实现额可以单独加锁，继承了ReentrantLock，也就是说Segment本身就是一个ReentrantLock。

在put时，在当前Segment内先加锁，然后在解锁

static final class Segment<K,V> extends ReentrantLock implements Serializable {
    private static final long serialVersionUID = 2249069246763182397L;
    transient volatile HashEntry<K,V>[] table;
    transient int count;
    transient int modCount;
    transient int threshold;
    final float loadFactor;
}

HashTable中，每个方法都是由synchronized修饰的。

与HashTable相比，通过这种方式，ConcurrentHashMap 减少了锁的粒度，从而允许多个写操作可以并发执行，只要它们操作的是不同的段。

JDK1.8

首先，虽然分段锁提高了并发性，但在段数固定的情况下，并发很高的时候仍可能导致热点段，从而成为性能瓶颈。另外，由于每个段都是独立的结构，这可能导致较高的内存占用。

所以，JDK 1.8 对 ConcurrentHashMap 的实现进行了重大改进，不再使用分段锁，而是采用了一种基于节点锁的方法，并且在内部大量使用了 CAS 操作来管理状态。这种新的设计旨在提供更高的并发级别并减少锁的争用。

为了进一步提升并发度，降低内容占用，JDK 1.8 对 ConcurrentHashMap 的实现进行了重大改进，不再使用分段锁，而是采用了一种基于节点锁的方法，采用“CAS+synchronized”的机制来保证线程安全。这种新的设计旨在提供更高的并发级别并减少锁的争用。

JDK 1.8中锁的场景，是针对节点加锁的，并不是像1.7中基于段，那么也就意味着，这种情况下，并发冲突要小得多了。毕竟同一个hashMap中，同时去写同一个节点的概率还是很低的。所以，这种情况下，并发冲突并不高。

而这种并发冲突不高时，synchronized就不会频繁的升级为重量级锁，大部分情况下偏向锁和轻量级锁就搞定了。所以，这时候，synchronized和ReentrantLock相比，其实加锁的性能上的差别几乎可以忽略不计了；

首先就是synchronized 无需手动锁管理，编程模型更简单，因为开发者不需要明确地调用锁的获取和释放方法，这减少了因忘记释放锁导致的死锁风险。

其次，synchronized则是JVM内置的语义，JVM能够在运行时作出相应的优化措施，比如锁粗化、锁消除等。这些是ReentrantLock不具备的。

另外，当获取锁获取失败时，synchronized会通过自旋避免线程被挂起，而ReentrantLock 会导致线程挂起。而线程不需要挂起的话就可以减少线程上下文切换的开销。

并且，不需要挂起，就意味着也不需要唤醒，所以synchronized的获取锁的效率也就会更高一些。

还有就是，ReentrantLock 是一个独立的对象，而 synchronized 是利用对象头（Object Header）中的一部分位标记来实现的锁。对于 ReentrantLock，每次使用都需要实例化一个 ReentrantLock 对象。这个对象除了存储锁的状态外，还可能包含其他一些控制并发访问的状态信息，如持有锁的线程、等待队列等，并且还有AQS的支持中需要存储队列。所以他的内存开销会更大一些。

ConcurrentHashMap在使用时，和HashMap有一个比较大的区别，那就是HashMap中，null可以作为键或者值都可以。而在ConcurrentHashMap中，key和value都不允许为null。

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;
            if (tab == null || (n = tab.length) == 0)
                tab = initTable();//初始化Node数组
            else if ((f = tabAt(tab, i = (n - 1) & hash)) == null) {//根据hash获取数组下标，如果该位置为空，则使用cas操作新增节点
                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)//如果当前节点在移动，则帮助移动rehash
                tab = helpTransfer(tab, f);
            else {
                V oldVal = null;
                synchronized (f) {//使用synchronized 锁住头节点
                    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)//链表元素大于8，就转换成红黑树
                        treeifyBin(tab, i);
                    if (oldVal != null)
                        return oldVal;
                    break;
                }
            }
        }
        addCount(1L, binCount);
        return null;
    }

ConcurrentHashMap的负载因子无法修改。
Node的hash字段的几种含义：
ForwardingNode的hash=-1，
红黑树头节点TreeNode的hash=-2，
其他就是普通节点hash>0

sizeCtl

sizeCtrl==-1
表示当前的散列表正在初始化，线程通过cas方式将0修改为-1，修改成功的线程才可以去初始化散列表。cas失败，则去自旋检查散列表是否被初始化出来，如果没初始化然后sizeCtl<0，就调用Thread.yield()暂时放弃cpu的执行权。

sizeCtl>0并且散列表初始化完成之后，表示下一次扩容的阈值。

sizeCtl<0并且不等于-1，表示当前散列表正处于扩容状态，高16位表示扩容标识戳（通过散列表长度换算成二进制，二进制的前面多少个0），低16位表示参与扩容工作的线程数+1。

扩容标识戳的计算方式：
扩容标识戳比较特殊，必须保证每个线程计算出来的值是一致的。首先计算出二进制下的散列表长度前面有多少个0，然后和1左移15位做一个或操作，接着在左移16位，最后结果+2。

            else if (tab == table) {
                int rs = resizeStamp(n);
                if (sc < 0) {
                    Node<K,V>[] nt;
                    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);
            }

    static final int resizeStamp(int n) {
        return Integer.numberOfLeadingZeros(n) | (1 << (RESIZE_STAMP_BITS - 1));
    }

addCount

如何统计当前散列表的数据量

实际使用的是一个LongAdder

为什么不使用AtomicLong
高并发情况下，LongAdder性能更好，AtomicLong竞争导致性能下降

扩容

迁移前的准备工作

设置sizeCtl：首先根据当前散列表长度计算出一个标识，作为高16位，然后低16位位参与扩容线程数+1，然后设置到sizeCtl中。
初始化新的散列表：将新表的地址设置到nextTable字段中。
设置transferIndex：该字段记录了迁移的进度。迁移操作时从高位桶开始，往下标0迁移。

迁移的过程

首先计算步长stride，然后cas修改transferIndex，操作成功之后，获得操作区间，就将这部分区间进行迁移操作。迁移时对头结点加锁，迁移一个桶后，在该桶中创建一个ForwardingNode节点。一直循环修改transferIndex等操作，直到全部迁移完毕。

迁移完的桶如何标记ForwardingNode

当某一个桶中数据迁移完毕时，会创建一个ForwardingNode对象，用来表示指定桶中已经被迁移完毕的。ForwardingNode中有一个指向新表的字段，还提供了一个查询方法，当我们查询的时候碰到桶位他是fwd节点时，说明查询的数据已经被迁移到了新表，直接通过fwd节点的find方法重新定位到新表上查询。

散列表在扩容时，再来一个写请求怎么处理

如果写操作访问的桶还没有被迁移，先拿到桶的锁，正常进行插入操作。

如果写操作访问的桶的头结点时fwd节点，会加入进来帮助扩容，首先计算步长stride，然后cas修改transferIndex，操作成功之后，就将这部分区间进行迁移操作。一直循环该操作直到全部迁移完毕，接着在进行更新操作。

扩容期间，扩容工作线程如何维护sizeCtl的低16位

每个线程在加入到扩容操作之前都会讲sizeCtl的低16位加一，执行一段之间后获取不到任务之后就退出扩容任务，退出之前会将低16位减一。

最后一个退出扩容任务的线程需要执行哪些收尾工作

线程在退出扩容任务时会将sizeCtl低 16位减一，当修改后的值发现为1时，那么当前线程就是最后一个退出现场了。
首先会重新检查一遍老表，看看有没有遗漏的slot，判断条件是slot上的节点是不是fwd节点，如果是就跳过，如果不是，当前线程就迁移这个slot的数据。
然后将新表的引用保存到map.table字段上，在根据新表的长度计算出下一次扩容的阈值，保存到sizeCtl上。

红黑树读写问题

桶升级成红黑树，且当前红黑树上有读线程访问，再来写请求怎么办

这个时候不能进行写操作，因为写操作会触发红黑树失衡，需要触发自平衡操作，导致树结构发生变化，这时候读线程还在树上面读，可能会出现问题。

TreeBin对象有一个int类型的state字段，读线程在读数据之前都会通过cas的方式将state的值+4，读取完毕之后会-4.
写线程在写数据到红黑树之前会检查state字段，判断该state是否为0，为0则说明没有线程在访问，可以进行写操作。然后通过cas的方式将state设置为1，独占锁，其他线程来了就不能对该红黑树进行读写了。

state如果不是0， 并且也不是1，则说明有读线程在读操作，此时不能进行写操作，当前线程会将自己的现场引用设置到TreeBin中，然后将state的第二位bit位设置为1 ，则表示有写现场处于等待状态，然后该线程通过LockSupport.park将自己挂起。
当读线程结束时会将state-4，然后再检查state的值是不是等于2，如果等于2，则将TreeBin中的写线程唤醒 。

红黑树上执行写操作，此时再来读请求怎么办

TreeBin中保留了一个链表和一个红黑树，当state为1时，表示有线程正在写操作，读请求会直接到链表上去进行访问数据。

总结：红黑树中，读在什么情况下都可以，在有写线程时使用TreeBin链表访问数据。写数据时，如果发现有读线程，则state+2，等读线程使用完成之后，发现state为2，则唤起等待的写线程。