ConcurrentHashMap

1、JDK1.8

PUT流程：

1、如果没有初始化就先调用initTable（）方法来进行初始化过程
2、如果没有hash冲突就直接CAS插入
3、如果还在进行扩容操作就先进行扩容
4、如果存在hash冲突，就加锁来保证线程安全，这里有两种情况，一种是链表形式就直接遍历到尾端插 入，一种是红黑树就按照红黑树结构插入，
5、最后一个如果该链表的数量大于阈值8，就要先转换成黑红树的结构，break再一次进入循环
6、如果添加成功就调用addCount（）方法统计size，并且检查是否需要扩容

2、总结

其实可以看出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使用红黑树来优化链表，基于长度很长的链表的遍历是一个很漫长的过程，而红黑树的遍历效率是很快的，代替一定阈值的链表，这样形成一个最佳拍档
JDK1.8为什么使用内置锁synchronized来代替重入锁ReentrantLock，我觉得有以下几点：
因为粒度降低了，在相对而言的低粒度加锁方式，synchronized并不比ReentrantLock差，在粗粒度加锁中ReentrantLock可能通过Condition来控制各个低粒度的边界，更加的灵活，而在低粒度中，Condition的优势就没有了
JVM的开发团队从来都没有放弃synchronized，而且基于JVM的synchronized优化空间更大，使用内嵌的关键字比使用API更加自然
在大量的数据操作下，对于JVM的内存压力，基于API的ReentrantLock会开销更多的内存，虽然不是瓶颈，但是也是一个选择依据

具体链接：
1、http://mp.weixin.qq.com/s?__biz=MjM5NzMyMjAwMA==&mid=2651478868&idx=1&sn=1aa298b9ba67ab33ea8af9c7627a27da&chksm=bd25372b8a52be3d9806e688cade686e668a075273ec662e0889978c6003d5be2a5fb411c15c&mpshare=1&scene=23&srcid=0814kPFCwNXdHqGWB4fIK4VT#rd
2、http://mp.weixin.qq.com/s?__biz=MjM5NzMyMjAwMA==&mid=2651478868&idx=2&sn=0afcac5c520e54672f2031cb92a359cf&chksm=bd25372b8a52be3d1c21c8db8e7d441636e8cf933f42332aa7d583d5fec655fbcb0b7673feb6&mpshare=1&scene=23&srcid=0814PextxJ2yJeeN6wmBrTzp#rd