ConcurrentHashMap1.7源码分析

参考：https://www.cnblogs.com/liuyun1995/p/8631264.html

HashMap不是线程安全的，其所有的方法都未同步，虽然可以使用Collections的synchronizedMap方法使其线程安全，但是针对的只是当前的map对象。对此，

JDK提供了线程安全的Hashtable，其所有的方法都是同步的，即使用Synchronized关键字进行加锁，但是也导致了同一时刻只能有一个线程操作哈希表，影响

性能，所以又提供了效率较高的线程安全的哈希表ConcurrentHashMap，其内部使用分段锁将锁进行细粒度化，从而使多个线程能够同时操作哈希表，大大提

高了性能。下面是其内部结构示意图：

Like {@link Hashtable} but unlike {@link HashMap}, this class
 does <em>not</em> allow {@code null} to be used as a key or value

和Hashtable一样，不允许null键和null值

Concurrent1.7和1.8的区别：

1.7中采用Segment+HashEntry的方式进行实现，并发控制使用ReentrantLock来实现。

　　每一个Segment元素存储的是HashEntry数组+链表，和HashMap的数据结构相同

1.8中放弃了Segment臃肿的设计，取而代之的是采用Node数组+链表+红黑树的数据结构来实现，当链表的长度大于8时会转化为红黑树。

　　并发控制使用 Synchronized+CAS来保证

　　JDK1.8版本的ConcurrentHashMap的数据结构已经接近HashMap，相对而言，ConcurrentHashMap只是增加了同步的操作来控制并发，从JDK1.7版本的ReentrantLock+Segment+HashEntry，到JDK1.8版本中synchronized+CAS+HashEntry+红黑树,相对而言，总结如下思考

JDK1.8的实现降低锁的粒度，JDK1.7版本锁的粒度是基于Segment的，包含多个HashEntry，而JDK1.8锁的粒度就是HashEntry（首节点）
JDK1.8版本的数据结构变得更加简单，使得操作也更加清晰流畅，因为已经使用synchronized来进行同步，所以不需要分段锁的概念，也就不需要Segment这种数据结构了，由于粒度的降低，实现的复杂度也增加了
JDK1.8使用红黑树来优化链表，基于长度很长的链表的遍历是一个很漫长的过程，而红黑树的遍历效率是很快的（logn），代替一定阈值的链表，这样形成一个最佳拍档

JDK1.8为什么使用内置锁synchronized来代替重入锁ReentrantLock：
　　1、因为粒度降低了，在相对而言的低粒度加锁方式，synchronized并不比ReentrantLock差，在粗粒度加锁中ReentrantLock可能通过Condition来控制各个低粒度的边界，

　　　　更加的灵活，而在低粒度中，Condition的优势就没有了
　　2、JVM的开发团队从来都没有放弃synchronized，而且基于JVM的synchronized优化空间更大，使用内嵌的关键字比使用API更加自然
　　3、在大量的数据操作下，对于JVM的内存压力，基于API的ReentrantLock会开销更多的内存，虽然不是瓶颈，但是也是一个选择依据

　　原文：https://blog.csdn.net/qq296398300/article/details/79074239

以下源码基于Java 1.7版本

public class ConcurrentHashMap<K, V> extends AbstractMap<K, V>
        implements ConcurrentMap<K, V>, Serializable {
    private static final long serialVersionUID = 7249069246763182397L;

其成员变量：

  /**
     * The maximum number of segments to allow; used to bound
     * constructor arguments. Must be power of two less than 1 << 24.
　　　* 分段锁的最大数量
     */
    static final int MAX_SEGMENTS = 1 << 16; 

    /**
     * Number of unsynchronized retries in size and containsValue
     * methods before resorting to locking. This is used to avoid
     * unbounded retries if tables undergo continuous modification
     * which would make it impossible to obtain an accurate result.
　　　* 分段锁的最小数量
     */
    static final int RETRIES_BEFORE_LOCK = 2;
    /**
     * Mask value for indexing into segments. The upper bits of a
     * key's hash code are used to choose the segment.
     * 分段锁的掩码值
     */
    final int segmentMask;

    /**
     * Shift value for indexing within segments.
     * 分段锁的移位值
     */
    final int segmentShift;

    /**
     * The segments, each of which is a specialized hash table.
     * 分段锁数组
     */
    final Segment<K,V>[] segments;

Segment是ConcurrentHashpMap的一个静态内部类：

 static final class Segment<K,V> extends ReentrantLock implements Serializable {
 static final int MAX_SCAN_RETRIES =
            Runtime.getRuntime().availableProcessors() > 1 ? 64 : 1;
 transient volatile HashEntry<K,V>[] table;
 transient int count;
 transient int modCount;

 transient int threshold;
 final float loadFactor;

Segment继承了ReentrantLock ，所以其本质上是一个锁。

分段锁即是由Segment来实现的，它继承于ReentrantLock，用来管理它辖区内的各个HashEntry。ConcurrentHashMap被Segment分成了很多小区，Segment就相当于小区保安，

HashEntry列表相当于小区业主，小区保安通过加锁的方式，保证每个Segment内都不发生冲突。

put和remove方法，对于Segment内部元素和计数器的更新，全部处于锁的保护下，如Segment.put()方法的第一行：

HashEntry<K,V> node = tryLock() ? null : scanAndLockForPut(key, hash, value);