Jdk1.6和1.7版本中ConcurrentHashMap的弱

前言：
昨天看技术论坛时看到了一篇<<为什么ConcurrentHashMap是弱一致的>>文章，其中的弱一致性是基于Jdk1.6版本的ConcurrentHashMap源码分析的，而在Jdk1.7和Jdk1.8中ConcurrentHashMap的设计都进行了一定程度的改良，是否仍然存在1.6版本中的弱一致性呢？
本文为了分析方便，假设有两个线程对一个ConcurrentHashMap实例进行并发处理，采用put-get这一并发操作组合来分析数据的一致性，put-get组合表示一个线程执行put方法时另一个线程执行get方法。另外，文章从1.6版本和1.7版本两个维度同时分析同一组合操作时的现象，进一步验证结论。
阅读此文章读者可能需要Java内存模型(JMM)、volatile内存语义、Happens Before关系、CAS、AQS、ConcurrentHashMap不同版本实现原理等基础前驱知识，文章只对一致性问题进行分析

在分析之前首先要知道ConcurrentHashMap在1.6和1.7中用volatile修饰的变量有哪些，如下表所示

1.6	1.7
Segment.count	Segment.HashEntry[]
Segment.HashEntry[]	Segment.HashEntry.value
Segment.HashEntry.value	Segment.HashEntry.next

众所周知，ConcurrentHashMap使用锁分离技术，初始时有16个Segment段组成，一个Segment段包含一个类型为HashEntry的数组table，一个HashEntry元素又存在key-value的键值对，以及指向下一个HashEntry元素的指针next
所以，表中的Segment.count表示每个Segment段中HashEntry[]内元素的数量；Segment.HashEntry[]表示Segment段内的HashEntry[]数组；Segment.HashEntry.value表示一个HashEntry元素中的value值；Segment.HashEntry.next表示HashEntry链表中下一个元素

图1. 1.6版本put方法 图2. 1.6版本get方法

因为count被volatile修饰，因此标注1是对volatile的读操作，同理标注2也是对volatile修饰的table(HashEntry[])的读操作；根据Happens Before规则中的程序顺序规则(一个线程中的每个操作，happens-before于该线程中的任意后续操作)，可以看出 1 happens before 2 happens before 3 happens before 4。其中，标注3是对普通变量的普通写操作，标注4是对volatile变量count的写操作；同样的道理在图2中存在5 happens before 6
那么我们模拟一下两个线程分别操作put方法和get方法的情况，首先是“正常”的情况

图3. 1.6版本下数据一致性正常的情况

图中因为标注1、3、4在同一线程中，因此存在happens before关系，另一个线程的5和6也存在happens before关系；此外，根据Happens Before规则中的volatile变量规则(对一个volatile域的写，happens-before于任意后续对这个volatile域的读)可以推理出4 happens before 5，因为4是对volatile变量count的写操作，5是对count的读操作。在根据Happens Before规则中的传递性(如果A happens-before B，且B happens-before C，那么A happens-before C)，最终推出1 happens before 2 happens before 3 happens before 4 happens before 5 happens before 6，因此此时数据的一致性是得到保证的。那么我们再来看看弱一致的情况

图4. 1.6版本下数据弱一致性的情况

我们更改了4、5执行的顺序，一个线程先执行对volatile变量count的读操作，之后另一个线程再执行对count的写操作，这样4、5之间就不存在happens before关系了，并且上面分析过3的操作只是普通变量的读写操作，而5是对volatile变量table的读操作，因此3、5之间也不存在happens before关系，6中读取的并不是3处添加新HashEntry的最新table，这就导致了数据的弱一致性
下面我们来看看在Jdk1.7中ConcurrentHashMap的put和get方法

图5. 1.7版本put方法 图6. 1.7版本get方法

因为table为volatile修饰，因此标注1是一个volatile读，用一个局部非volatile修饰引用了volatile修饰的volatile，这里必须要注意一个知识点：volatile修饰的是reference，不是对象的实例，也就是说table指向了一个堆内内容为HashEntry[]内容的空间，这里的volatile修饰的是这个table在栈内的引用，不是栈内地址指向的堆内内容，而HashEntry<K,V>[] tab = table相当于又用了另一个变量tab指向了变量table指向的同一块内存地址，但是tab引用并没有被volatile修饰，所以tab是不具有volatile语义的相关特性的
标注2调用了HashEntry<K,V> entryAt(HashEntry<K,V>[] tab, int i)方法，源码如下：

图7. entryAt方法
entryAt方法调用了UNSAFE类的getObjectVolatile，该方法是根据第二个参数的offset偏移量查找对应第一个参数中的值，该方法是支持volatile读语义的，其底层是在entryAt方法插入一个LoadLoad和一个LoadStore内存屏障防止CPU可能的指令重排序
接着再回去看图5中的标注3处，将新加入的HashEntry实例放在HashEntry[]特定的位置上，下面是其源码 图7 setEntryAt方法
同样的setEntryAt方法内部也调用了UNSAFE类的putOrderedObject方法，这里又存在一个坑，很多文章在分析该方法时都说其是一个具有volatile语义的方法，或者是否具有volatile语义依赖于第一个参数是否是volatile变量，但实际上putOrderedObject并不具有volatile语义，该方法的底层省去了volatile写的StoreLoad内存屏障，只添加了StoreStore内存屏障，所以只能保证putOrderedObject方法之前的内存可见性，不能保证数据的一致性，读者可以参考JUC中Atomic class之lazySet的一点疑惑，对该问题分析的非常漂亮，源码扒到了祖坟上
根据Happens Before规则中的程序顺序规则可以得出1 happens before 2 happens before 3，同理推出图6中4 happens before 5 happens before 6，但是对比图5和图6的代码发现，图5中和图6中只有table一个被volatile修饰的变量被共享，而且在put方法中table是volatile读，get方法中table也是volatile读，按照Happens Before规则中的volatile变量规则，必须存在另一个volatile的写，在这里也就是对于table变量的写，且写要在读之前才会行成Happens Before关系，很明显也不满足
我们再对比1.6版本中是如何完成“部分数据一致性”的，在1.6中count变量被volatile修饰了，因此该变量可以作为两个线程发生volatile的媒介，但在1.7版本中，count变量没有被volatile修饰，因此也不存在依靠该变量发生Happens Before关系的可能性。put方法和get方法中都存在对于局部变量tab的volatile操作，但经过逃逸性分析，这里的局部变量并不会逃逸到另一个线程中，所以也不会存在Happens Before语义
最后只剩标注4中的UNSAFE.getObjectVolatile(segments, u)，上面分析过，虽然参数中的segments没有被volatile修饰，但是getObjectVolatile会强制在变量读取之后加上LoadLoad和LoadStore内存屏障行成volatile读语义，但在put方法时也不存在对于该共享变量的volatile写操作，也就更谈不上行成Happens Before关系了。因此1.7版本ConcurrentHashMap的数据弱一致性也得以论证

后记
在写这篇文章的过程中发现很多之前“掌握”的知识其实非常肤浅，迫使我查阅各种资料和规范，也得到了很多大牛的帮助，即便写完文章也感觉有各种理解的不恰当的地方，摒弃浮躁，学无止境，永远以学生的心态脚踏实地前进