一、ConcurrentHashMap的由来
原因可以总结成以下两点：
1、HashMap是非线程安全的，在并发的场景中可能导致死循环
2、hasetable虽然线程安全但效率却很低下
1>线程不安全的HashMap
下面代码取自并发编程艺术一书中，执行该代码会引起死循环
top查看cpu使用率：
2>HashTable的效率低下
HashTable使用内置锁synchronized来保证线程安全，在高并发的场景下，当线程1访问hasetable的同步方法时，此时线程1正在执行put操作，其他线程此时既不能执行put操作也不能执行get操作，只能等待该线程释放锁，再竞争获取锁。
在jdk1.7中ConcurrentHashMap采用锁分段的技术来提升并发的访问效率。简单来说就是给每一段数据配一把锁，当一个线程占用锁访问其中一个段数据的时候，其他段的数据也能被其他线程访问从而提升了并发的访问效率。
二、ConcurrentHashMap的数据结构
ConcurrentHashMap是由Segment数组结构和HashEntry数组结构组成,每个HashEntry是一个链表结构。Segment继承了ReentrantLock，因此Segment是一种可重入锁，在ConcurrentHashMap里扮演锁的角色；HashEntry则用于存储键值对数据。一个ConcurrentHashMap里包含一个Segment数组。Segment的结构和HashMap类似，是一种数组和链表结构。一个Segment里包含一个HashEntry数组，每个HashEntry是一个链表结构的元素，每个Segment守护着一个HashEntry数组里的元素，当对HashEntry数组的数据进行修改时，必须首先获得与它对应的Segment锁
Segment和HashEntry的源码如下：
三、ConcurrentHashMap的构造函数
initialCapacity:顾名思义初始化容量，表示ConcurrentHashMap的初始化容量也就是HashEntry的数量，默认值为16，最大值为2的30次方
loadFactor:负载因子，默认值为0.75f，当Segment里的HashEntry数组容量超过阈值，这个阈值等于loadFactor * cap,就需要rehash
concurrencyLevel：并发级别，默认值为16，segments数组的长度ssize是通过concurrencyLevel计算得出的，concurrencyLevel的最大值是65535，这意味着segments数组的长度最大为65536。Segment的个数是大于等于concurrencyLevel的第一个2的n次方的数。比如，如果concurrencyLevel为12，13，14，15，16这些数，则Segment的数目为16(2的4次方)
四、put方法分析
这里可以得出两点：
1、ConcurrentHashMap不能存空值
2、根据hase值找到对应的segment进而调用其内部的put方法存放数据
这里先考虑当前线程获取到锁的情况：
1、根据hash值找到数组相应bucket中的第一个链节点
2、遍历数组，如果在节点中能找到key相等的节点，则覆盖旧值；如果没有找到和key相等的节点，并创建一个新的节点，并将该节点作为链头插入当前链
3、如果容量超过阈值(capacity*loadFactor)并且数组长度没有达到最大数组长度则rehash。
这里可以总结为：
1、调用ReentrantLock的tryLock()获取到锁，循环结束
2、始终没有获取到锁，调用阻塞方法进入同步队列中等待被唤醒再次尝试获取锁
3、node的是否被实列化是获取锁的顺序以及一堆条件判断相结合的结果
简单来说：就是将 segment 数组中某个位置内部的HashEntry数组进行扩容2倍
五、get方法分析
根据hash值找到对应的segement，然后找到segment对应的table中的具体位置HaseEntry链表，顺着链表遍历查找就ok了。
六、remove方法分析
remove方法可以归纳为两点：
1、待删除节点是头结点，此时把头节点的next节点设置到头节点的位置，删除成功
2、待删除的节点不是头结点，则待删除节点的前节点的next指向待删除节点的的下一个节点，删除成功
到此jdk1.7的ConcurrentHashMap的主要内容已经分析完毕，下篇将会介绍JDK1.8关于ConcurrentHashMap的源码分析。
参考文章：
Doug Lea:《Java并发编程实战》
方腾飞、魏鹏、程晓明：《并发编程的艺术
欢迎关注微信公众号获取更多学习资源
