ConcurrentHashMap
ConcurrentHashMap 是 J.U.C 包里面提供的一个线程安全并且高效的 HashMap，所以 ConcurrentHashMap 在并发编程的场景中使用的频率比较高。
1.7与1.8的不同
ConcurrentHashMap 和 HashMap 的实现原理是差不多的，但是因为 ConcurrentHashMap 需要支持并发操作，所以在实现上要比hashmap稍微复杂一些。
JDK1.7 的实现
ConrruentHashMap 由一个个 Segment 组成，简单来说，ConcurrentHashMap是一个Segment数组，它通过继承ReentrantLock来进行加锁，通过每次锁住一个segment来保证每个segment内的操作的线程安全性从而实现全局线程安全。整个结构图如下
当每个操作分布在不同的 segment 上的时候，默认情况下，理论上可以同时支持 16 个线程的并发写入。
JDK1.8 的实现
取消了segment分段设计，直接使用Node数组来保存数据，并且采用Node数组元素作为锁来实现每一行数据进行加锁来进一步减少并发冲突的概率。
将原本数组+单向链表的数据结构变更为了数组+单向链表+红黑树的结构。为什么要引入红黑树呢？在正常情况下，key hash之后如果能够很均匀的分散在数组中，那么table数组中的每个队列的长度主要为 0 或者 1.但是实际情况下，还是会存在一些队列长度过长的情况。如果还采用单向列表方式，那么查询某个节点的时间复杂度就变为 O(n); 因此对于队列长度超过8的列表，JDK1.8采用了红黑树的结构，那么查询的时间复杂度就会降低到 O(logN),可以提升查找的性能；
put方法
final V putVal(K key, V value, boolean onlyIfAbsent) { }
1. 计算hash值
2. 如果数组为空，则进行数组初始化
3. 通过 hash 值对应的数组下标得到第一个节点; 以 volatile 读的方式来读取 table 数组中的元素，保证每次拿到的数据都是最新的（volatile 的数组只针对数组的引用具有 volatile的语义，而不是它的元素）
4. 如果该下标返回的节点为空，则直接通过 cas 将新的值封装成 node 插入即可；如果 cas 失败，说明存在竞争，则进入下一次循环。
private final Node<K,V>[] initTable() { }
数组初始化方法比较简单
被其他线程抢占了初始化的操作,则直接让出自己的 CPU时间片
如果拿到了则使用乐观锁CAS
默认数组长度为 16
默认负载因子 0.75
触发扩容机制 12
sizeCtl这个要单独说一下
如果没搞懂这个属性的意义，可能会被搞晕这个标志是在 Node 数组初始化或者扩容的时候的一个控制位标识，负数代表正在进行初始化或者扩容操作
-1 代表正在初始化
-N 代表有N-1 有二个线程正在进行扩容操作，这里不是简单的理解成 n个线程，sizeCt就是-N,这块后续在讲扩容的时候会说明
0 标识Node数组还没有被初始化，
正数 代表初始化或者下一次扩容的大小
private final void addCount(long x, int check) { }
总结一下该方法的逻辑：
x 参数表示的此次需要对表中元素的个数加几。check 参数表示是否需要进行扩容检查，大于等于0 需要进行检查，而我们的 putVal 方法的 binCount 参数最小也是 0 ，因此，每次添加元素都会进行检查。（除非是覆盖操作）
1.判断计数盒子属性是否是空，如果是空，就尝试修改 baseCount 变量，对该变量进行加 X。
2.如果计数盒子不是空，或者修改 baseCount 变量失败了，则放弃对 baseCount 进行操作。
3.如果计数盒子是 null 或者计数盒子的 length 是 0，或者随机取一个位置取于数组长度是 null，那么就对刚刚的元素进行 CAS 赋值。
4.如果赋值失败，或者满足上面的条件，则调用 fullAddCount 方法重新死循环插入。
5.这里如果操作 baseCount 失败了（或者计数盒子不是 Null），且对计数盒子赋值成功，那么就检查 check 变量，如果该变量小于等于 1. 直接结束。否则，计算一下 count 变量。
6.如果 check 大于等于 0 ，说明需要对是否扩容进行检查。
7.如果 map 的 size 大于 sizeCtl（扩容阈值），且 table 的长度小于 1 << 30，那么就进行扩容。
8.根据 length 得到一个标识符，然后，判断 sizeCtl 状态，如果小于 0 ，说明要么在初始化，要么在扩容。
9.如果正在扩容，那么就校验一下数据是否变化了（具体可以看上面代码的注释）。如果检验数据不通过，break。
10.如果校验数据通过了，那么将 sizeCtl 加一，表示多了一个线程帮助扩容。然后进行扩容。
11.如果没有在扩容，但是需要扩容。那么就将 sizeCtl 更新，赋值为标识符左移 16 位 —— 一个负数。然后加 2。 表示，已经有一个线程开始扩容了。然后进行扩容。然后再次更新 count，看看是否还需要扩容。
总结下来看，addCount 方法做了 2 件事情：
对 table 的长度加一。无论是通过修改 baseCount，还是通过使用 CounterCell。当 CounterCell 被初始化了，就优先使用他，不再使用 baseCount。
检查是否需要扩容，或者是否正在扩容。如果需要扩容，就调用扩容方法，如果正在扩容，就帮助其扩容。
有几个要点注意：
第一次调用扩容方法前，sizeCtl 的低 16 位是加 2 的，不是加一。所以 sc == rs + 1 的判断是表示是否完成任务了。因为完成扩容后，sizeCtl == rs + 1。
扩容线程最大数量是 65535，是由于低 16 位的位数限制。
这里也是可以帮助扩容的，类似 helpTransfer 方法。
private final void transfer(Node<K,V>[] tab, Node<K,V>[] nextTab) { }
扩容是 ConcurrentHashMap 的精华之一，扩容操作的核心在于数据的转移，在单线程环境 下数据的转移很简单，无非就是把旧数组中的数据迁移到新的数组。
但是这在多线程环境下，在扩容的时候其他线程也可能正在添加元素，这时又触发了扩容怎么办？可能大家想到的第一个解决方案是加互斥锁，把转移过程锁住，虽然是可行的解决方案，但是会带来较大的性能开销。
因为互斥锁会导致所有访问临界区的线程陷入到阻塞状态，持有锁的线程耗时越长，其他竞争线程就会一直被阻塞，导致吞吐量较低。而且还可能导致死锁。
而ConcurrentHashMap并没有直接加锁，而是采用CAS实现无锁的并发同步策略，最精华的部分是它可以利用多线程来进行协同扩容简单来说，它把 Node 数组当作多个线程之间共享的任务队列，然后通过维护一个指针来划分每个线程锁负责的区间，每个线程通过区间逆向遍历来实现扩容，一个已经迁移完的 bucket会被替换为一个ForwardingNode节点，标记当前bucket已经被其他线程迁移完了。
接下来分析一下它的源码实现
1、fwd:这个类是个标识类，用于指向新表用的，其他线程遇到这个类会主动跳过这个类，因 为这个类要么就是扩容迁移正在进行，要么就是已经完成扩容迁移，也就是这个类要保证线 程安全，再进行操作。
2、advance:这个变量是用于提示代码是否进行推进处理，也就是当前桶处理完，处理下一个 桶的标识
3、finishing:这个变量用于提示扩容是否结束用的
高低位对每一个Node的扩容
ConcurrentHashMap在做链表迁移时，会用高低位来实现。
就是重新计算一次hash,分成高低位链表，低位的位置不变，高位则+旧链表长度
最后一点的就是链表转红黑树
Node数组长度超过64,链表长度超过8
构造一棵树,下次插入的时候还会进行红黑树的平衡操作,旋转、变色。
