和Map的区别在于 在put操作的时候进行了同步操作。get操作还是一样
总的数据结构是一个大的Segment套一堆HashEntry。
JDK1.7版本：ReentrantLock+Segment+HashEntry
JDK1.8版本：synchronized+CAS+HashEntry+红黑树
可以看出到了jdk1.8 锁的粒度进一步细化，那么为什么能够进一步细化并且使用synchronized替换1.7中的ReentrantLock，还是因为，synchronized锁升级的优化，使得锁在更细粒度下仍然有更好的表现
1.锁结构不同
在JDK1.7中，ConcurrentHashMap基于Segment+HashEntry数组实现的。Segment是Reentrant的子类，而其内部也维护了一个Entry数组，这个Entry数组和HashMap中的Entry数组是一样的。所以说Segment其实是一个锁，可以锁住一段哈希表结构，而ConcurrentHashMap中维护了一个Segment数组，所以是基于分段锁实现的。 而JDK1.8中，ConcurrentHashMap摒弃了Segment，而是采用synchronized+CAS+红黑树来实现的。锁的粒度也从段锁缩小为结点锁.
2.put()的执行流程有所不同
JDK1.7
ConcurrentHashMap要进行两次定位，先对Segment进行定位，再对其内部的数组下标进行定位。定位之后会采用自旋锁+锁膨胀的机制进行加锁，也就是自旋获取锁，当自旋次数超过64时，会发生膨胀，直接陷入阻塞状态，等待唤醒。并且在整个put操作期间都持有锁。
JDK1.8
只需要一次定位，并且采用CAS+synchronized的机制。如果对应下标处没有结点，说明没有发生哈希冲突，此时直接通过CAS进行插入，若成功，直接返回。若失败，则使用synchronized进行加锁插入。如果存在扩容，那么就去协助扩容,加完数据之后，再判断是否还需要扩容。
数据结构：synchronized+CAS+红黑树+数组+链表，因为synchronized进行了锁优化，性能提升了很多，直接使用Node数组来保存数据，以达到减少并发冲突概率，引入红黑树结构减低时间复杂度。
/** Implementation for put and putIfAbsent */
final V putVal(K key, V value, boolean onlyIfAbsent) {
//不能存储为null的元素
if (key == null || value == null) throw new NullPointerException();
//进行hash运算
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)
// 默认创建长度为16的数组长度，加载因子为0.75的Map
tab = initTable();
//通过hash得到下标索引，以 volatile 读的方式来读取 table 数
//组中的元素，保证每次拿到的数据都是最新的
else if ((f = tabAt(tab, i = (n - 1) & hash)) == null) {
//槽位为null 创建一个新结点,通过cas插入node，如果cas失败，则代表出现锁竞争，进行自旋
如果插入成功，则修改addCount，检查是否需要扩容
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)
//进行一起扩容
tab = helpTransfer(tab, f);
//添加元素
else {
V oldVal = null;
synchronized (f) {
//定位下标索引
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) {
//是否满足树化条件（链表.length>8 && 容量>64）
if (binCount >= TREEIFY_THRESHOLD)
treeifyBin(tab, i);
if (oldVal != null)
return oldVal;
break;
}
}
}
//计数
addCount(1L, binCount);
return null;
}
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
//另一线程放弃该操作，进行自旋
//进行cas操作 将SIZECTL更新为-1，标识当前线程抢到了初始化资格
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;
//计算下一次的扩容长度 实际加载因子0.75 不像hashMap乘以0.75这里是右移
sc = n - (n >>> 2);
}
} finally {
//假设容量为16 16*0.75 = 12
sizeCtl = sc;
}
break;
}
}
return tab;
}
sizeCtl该变量是一个标记符，-1代表正在初始化 -N代表有线程正在扩容 0代表Node数组没有初始化。
3.get()操作
1.7
ConcurrentHashMap的get操作跟HashMap类似，只是ConcurrentHashMap第一次需要经过一次hash定位到Segment的位置，然后再hash定位到指定的HashEntry，遍历该HashEntry下的链表进行对比，成功就返回，不成功就返回null 我们发现整个get过程中使用了大量的volatile关键字,其实就是保证了可见性(加锁也可以,但是降低了性能),get只是读取操作,所以我们只需要保证读取的是最新的数据即可..
1.8
据计算出来的 hashcode 寻址，如果就在桶上那么直接返回值。
如果正在扩容，且当前节点已经扩容完成，那么根据ForwardingNode查找扩容后的table上的对应数据
如果是红黑树那就按照树的方式获取值。如果不满足那就按照链表的方式遍历获取值。
4.size操作
1.7
计算ConcurrentHashMap的元素大小是一个有趣的问题，因为他是并发操作的，就是在你计算size的时候，他还在并发的插入数据，可能会导致你计算出来的size和你实际的size有相差（在你return size的时候，插入了多个数据），要解决这个问题，JDK1.7版本用两种方案
1、第一种方案他会使用不加锁的模式去尝试多次计算ConcurrentHashMap的size，最多三次，比较前后两次计算的结果，结果一致就认为当前没有元素加入，计算的结果是准确的
2、第二种方案是如果第一种方案不符合，他就会给每个Segment加上锁，然后计算ConcurrentHashMap的size返回(美团面试官的问题,多个线程下如何确定size)
1.8
在JDK1.8版本中，对于size的计算，在扩容和addCount()方法就已经有处理了，可以注意一下Put函数，里面就有addCount()函数，早就计算好的，然后你size的时候直接给你。JDK1.7是在调用size()方法才去计算，其实在并发集合中去计算size是没有多大的意义的，因为size是实时在变的，只能计算某一刻的大小，但是某一刻太快了，人的感知是一个时间段，所以并不是很精确
put是时候如果看到 move = -1 代表正在扩容，此时会放弃任务去帮助迁移。helpTransfer，怎么帮，我会给他16个槽位。
