一、概述
在JDK1.7主要通过定义Segment分段锁来实现多个执行绪对ConcurrentHashMap的资料的并发读写操作。整个ConcurrentHashMap由多个Segment组成，每个Segment储存整个ConcurrentHashMap的一部分资料，Segment结合ReentrantLock，即Segment继承于ReentrantLock，来实现写互斥，读共享，具体为有多少个Segment，则任何时候可以最多支援这么多个执行绪同时进行写操作，任意多个执行绪进行读操作。在ConcurrentHashMap的Segment实现中，对写操作使用ReentrantLock来进行加锁，读操作不加锁，通过volatile来实现执行绪之间的可见性。具体可以参考我的另外一篇文章：Java并发包源代码分析：ConcurrentHashMap（JDK1.7版本）在JDK1.8中为了进一步优化ConcurrentHashMap的效能，去掉了Segment分段锁的设计，在资料结构方面，则是跟HashMap一样，使用一个杂凑表table阵列，即阵列 + 连结串列或者阵列 + 红黑树。而执行绪安全方面是结合CAS机制来实现的，CAS底层依赖JDK的UNSAFE所提供的硬件级别的原子操作。同时在HashMap的基础上，对杂凑表table阵列和连结串列节点的value，next指标等使用volatile来修饰，从而实现执行绪可见性。二、核心字段
杂凑表table阵列，如下与HashMap一样也是使用一个Node型别的阵列table来定义的，不同之处是使用volatile修饰该阵列。baseCount和counterCells：用来记录当前ConcurrentHashMap存在多少个元素使用的，在进行增删连结串列节点时，预设是更新baseCount的值即可，如果同时存在多个执行绪并发进行对连结串列节点的增删操作，则放弃更新baseCount，而是counterCells阵列中新增一个CounterCell，之后在计算size的时候，累加baseCount和遍历并累加counterCells。// 链式杂凑表阵列
transient volatile Node[] table;
// 用于size方法统计元素个数使用
private transient volatile long baseCount;
private transient volatile CounterCell[] counterCells;
连结串列节点Node的定义：value，next使用volatile修饰保证执行绪可见性。
三、核心方法
1. UNSAFE：硬件级别的原子操作
主要定义了获取，更新，新增连结串列节点Node的方法，具体为基于UNSAFE类提供的硬件级别的原子操作来保证执行绪安全，而不是通过加锁机制，如synchronized关键字，ReentrantLock重入锁来实现，即无锁化。
2.put写操作
写操作主要在putVal方法定义，实现逻辑与HashMap的putVal基本一致，只是相关操作，如获取连结串列节点，更新连结串列节点的值value和新增连结串列节点，都会使用到UNSAFE提供的硬件级别的原子操作，而如果是更新连结串列节点的值或者在一个已经存在的连结串列中新增节点，则是通过synchronized同步锁来实现执行绪安全性。
如果当前需要put的key对应的连结串列在杂凑表table中还不存在，即还没新增过该key的hash值对应的连结串列，则呼叫UNSAFE的casTabAt方法，基于CAS机制来实现新增该连结串列头结点到杂凑表table中，避免该执行绪在新增该连结串列头结的时候，其他执行绪也在新增的并发问题；如果CAS失败，则进行自旋，通过继续第2步的操作；如果需要新增的连结串列已经存在杂凑表table中，则通过UNSAFE的tabAt方法，基于volatile机制，获取当前最新的连结串列头结点f，由于f指向的是ConcurrentHashMap的杂凑表table的某条连结串列的头结点，故虽然f是临时变数，由于是引用共享的该连结串列头结点，所以可以使用synchronized关键字来同步多个执行绪对该连结串列的访问。在synchronized(f)同步块里面，则是与HashMap一样遍历该连结串列，如果该key对应的连结串列节点已经存在，则更新，否则在连结串列的末尾新增该key对应的连结串列节点。使用synchronized同步锁的原因：因为如果该key对应的节点所在的连结串列已经存在的情况下，可以通过UNSAFE的tabAt方法基于volatile获取到该连结串列最新的头节点，但是需要通过遍历该连结串列来判断该节点是否存在，如果不使用synchronized对连结串列头结点进行加锁，则在遍历过程中，其他执行绪可能会新增这个节点，导致重复新增的并发问题。故通过synchronized锁住连结串列头结点的方式，保证任何时候只存在一个执行绪对该连结串列进行更新操作。锁的范围缩小：相对于JDK1.7的Segment分段锁，即分段锁的写操作，在操作之前需要先获取lock锁，即不管是（1）连结串列不存在，新增连结串列头结点，（2）还是更新连结串列节点，（3）还是在已经存在的连结串列中新增节点，都需要先获取lock锁，而在JDK1.8的写操作中，（1）如果该连结串列不存在，新增连结串列头的时候是不需要加锁的，因为是往杂凑表table阵列的某个位置填充值，不需要遍历连结串列之类的，所以可以基于UNSAFE的casTabAt方法，即CAS机制检查table阵列的该位置是否存在元素（连结串列头结点）来实现执行绪安全，这是写操作最先检查的；如果该连结串列已经存在，即（2）（3）则需要通过synchronized来锁住该连结串列头结点，而在JDK1.7的实现中是锁住该Segment内部的整个杂凑表table阵列，所以这里也是一个性能提升的地方，缩小了锁的范围。3.get读操作
get读操作由于是从杂凑表中查询并读取连结串列节点资料，不会对连结串列进行写更新操作，故基于volatile的happend-before原则保证的执行绪可见性（即一个执行绪的操作对其他执行绪可见），即可保证get读取到该key对应的最新连结串列节点，整个过程不需要进行加锁。具体为table和Node的value和next均是volatile修饰。
4.size容量计算
size方法为计算当前ConcurrentHashMap一共存在多少连结串列节点，与JDK1.7中每次需要遍历segments阵列来计算不同的是，在JDK1.8中，使用baseCount和counterCells阵列，在增删连结串列节点时，实时更新来统计，在size方法中直接返回即可。整个过程不需要加锁。并发修改异常处理：CounterCell的value值为1，作用是某个执行绪在更新baseCount时，如果存在其他执行绪同时在更新，则放弃更新baseCount的值，即保持baseCount不变，而是各自往counterCells阵列新增一个counterCell元素，在size方法中，累加counterCells阵列的value，然后与baseCount相加，从而获取准确的大小。
