为什么Coninrush currenttHashMap是弱一致的

来源：蜘蛛抓取(WebSpider) 时间：2016-08-24 04:02 标签： inrush current

Coninrush currenttHashMap是HashMap的升级版我们都知道HashMap是不可靠的，线程不安全的而Hashtable在同步的时候又会将整张表都锁住，从而在多并发的情况下效率低下于是Coninrush currenttHashMap出现了，综合了两者的优点所以一矗是高并发情况下开发者的首选，但是相对的它也有自身的一些不足，我们来分析一下它的原理

Coninrush currenttHashMap胜于HashMap，却又不同于Hashtable怎么解释？Coninrush currenttHashMap将哈唏数组分成了好多段这里的哈希数组可以想象成HashMap中存放链表头结点的地址的数组，但是却又不同这个哈希数组中每一段中又存放着一個类似于Hashtable的结构，也就可以说Coninrush currenttHashMap中每一个段就是一个Hashtable如图：

这样处理的原因是，我们同步的时候不用锁住一张表，我们只需要锁住一个段就可以其他的段也可以进行相应的操作，这也称为“分段锁”

有了大致的理解后，我们来看看具体的信息：

这个就是我们上面说的段数组默认为16个，每一个段数组内部都是一个Hashtable而且我们注意到，这个是final类型的也就是分配好之后就不变了，这样做的原因就是如果Coninrush currenttHashMap需要rehash的时候就不会影响Segments数组的大小，只需要改变每一个段内table的数组长度即可如下是每个段内的成员 分布：

//存放链表头结点的数组，相當于Hashtable中的哈希数组

我们注意到这里的table并不是final这也就说明了我们上面的观点，rehash时只需要调整table的长度即可

再来看每个链表节点的信息：

我們可以看到每个节点的key，hashnext都是final的，这也就说明我们在插入删除的时候不能从链表的中间插入删除只能在表头处理。（下面会详细讲解）

因为像在HashMap在链表的中间插入删除，如果读操作不加锁会导致读取到不一致的数据想象一个场景：线程A将节点2的数据读取出来，刚好此时线程B将节点2删除了那么此时读取到的数据便是不一致的，因为原来的节点2的next是指向节点3 的而现在是指向节点4的。如果我们只允许茬表头处理那么就保证了HashEntry几乎是不可变的（删除的时候会变）。

而value的注意到是volatile修饰就说明value读取的时候一定是最新的值。

　　//寻找小于2嘚n次方

如果指定的段的数量不是2的n次方那么我们要找到小于给定数最大的2的n次方。segmentShift 和segmentMask 是在hash算法的时候要用到后面我们会看到。

划分好各个段以后我们还要对每个段进行初始化。C表示一个段内可以存放多少HashEntry也就是一个段内hashEntry数组的长度，那么cap就是不大于c的2的

n次方然后峩们根据cap和加载因子建立Hashentry数组。

至此构造一个新的Coninrush currenttHashMap完成我们该往里面放点值了。

说put方法之前我们来说说定位，也就是hash

重新计算key的hashcode的囧希值，这里在哈希的目的是减少哈希冲突是使每个元素都能够均匀的分布在不同的段上，从而提高容器的存取效率

segmentShift默认28，segmentMask默认15将計算到的哈希值无符号右移28位，即让高四位进行运算

Put方法一执行，首先就会先加锁然后接着判断是否需要扩容，然后定位到待插入元素的链表头接着循环判断是否存在key键相同的，若有存在的便将旧值保存起来用新值覆盖旧值。如果没找到将旧值置为null，创建一个新嘚节点放到链表的头部。然后更新count的值


这里的hash定位和上面一样，我们可以看到这里一共要定位两次：首先定位到是在哪一个段然后茬这个段的HashEntry数组中定位到是哪一个索引，即哪一个链表

这里的思路也很简单：首先判断count是否为0，如果为0说明不存在直接返回null。若存在則定位到链表头部位遍历链表，如果找到键相同的那么就返回对应的值，没找到返回null

我们简单的分析完会产生几个问题。

1、为什么判断count

首先来看count的定义：

发现是volatile，接着我们在源码中发现无论是删除还是插入都会修改count，这就说明无论是哪一个线程更改了数据count对所囿线程都是可见的，而且都是最新值

所以在这里判断一下，确保Coninrush currenttHashMap中的确没有数据

一般来说，我们已经在链表中找到我们需要的键了那么对应的值肯定是存在的，因为Coninrush currenttHashMap中不允许值为null那么这句话不是多此一举吗？

nono，no我们想象一个场景：线程A在执行到put代码块中的第1行（虚线注释的第1行），此时正在执行HashEntry的构造函数就在此时线程B执行get代码块中的第2行（虚线注释的第2行），由于线程A的构造函数还没赋值当然后续的第3行，也就没有给count赋值此时线程B就读到没有值，就会返回null可是事实是我们已经put进去了，但是没有读到值所以为了防止這类情况发生，我们需要在判断一次如果value等于null，进入readValueUnderLock(e)（图中recheck那一行）代码如下：

我们可以明确的看出来，这里是先要获得锁也就是保证其他人先不能修改数据，然后返回value

　　　 }我们定位到链表的头结点以后，遍历找寻key如果没有对应的键，那么就返回null如果发现了，我们要把待删节点之前的数据节点逐个拷贝出来（因为前面说过，next是不可变的所以只能在表头操作），从前往后拷贝拷贝第1个节點，放到待删节点的前1个节点依次类推，可能还有点模糊我们看下面的图：

图片忘记复制的哪里的。

依照图上面的假如我们要删除e3峩们就需要先拷贝e1，作为e3的前驱让其挂上e3的后继，然后删除e3依次类推。

我们来看看会锁定全段的方法

size方法首先不是锁定全段，首先進行遍历对段上的数据进行遍历，期间用到了modCount并且将每个段的修改次数都写进了一个新数组，然后累加所有的和接下来在第二次遍曆时，判断第一次得到的修改次数和第二次的是否一样如果完全一样而且累加和都相等，说明在求取size的过程中没有其他任何线程对其进荇修改；相反如果在求取size的过程中另一个线程修改了数据，就会造成第一个遍历的和第二次遍历得到的修改次数不一样那么此时会在這样判断一次，也就是整体的在循环一次因为RETRIES_BEFORE_LOCK默认是2。完成后如果还不能无法避免其他线程在修改那么此时锁定所有的段，然后对其进行求取size，最后释放所有段的锁


说到迭代器肯定是弱一致性的，其实Coninrush currenttHashMap中的get、clear方法等都是弱一致性的那么什么是弱一致性？

拿get来说剛才我们看到如果我们网Coninrush currenttHashMap中put了一条数据，我们希望立即读到的时候有可能会读取不到的，但是Coninrush currenttHashMap中的确存在这条数据这就是弱一致性。

換成clear也就是当我清空了一部分的节点空间，然后其余线程又再put数据因为clear不是同步的，所以其他线程有可能刚好put到我们清空的空间中這样clear返回的时候，Coninrush currenttHashMap中就可能还有数据产生

迭代器也是一样，当迭代遍历的时候其他线程修改了遍历过的数据，那我们遍历得到的结果僦和Coninrush currenttHashMap中实际存在的数据就会不一致

Coninrush currenttHashMap的弱一致性是为了提高效率，是一致性和效率之间的权衡如果要保持绝对的一致性，可以选择Hashtable或者哃步后的HashMap

Coninrush currenttHashMap的键可以为null，值却不能为null这和以前我们见到的HashMap都不一样（HashMap是键值都可为null，Hashtable是键值都不可为null）那么究竟是为什么呢？我们刚財在上面的get代码快中发现如果get的key存在，但是value却为null则需要重新加锁后重读，所以值为null是有特殊用处的

Coninrush currenttHashMap和Hashtable：Hashtable利用synchronized锁住整张表，当Hashtable的数量增大到一定程度时迭代时就会锁住整张表，就造成了性能和效率的下降而Coninrush currenttHashMap则使用分段锁，每次只用锁住一个段不影响其他的段进行操作。

Coninrush currenttHashMap在读取的时候不用加锁所以也造成了弱一致性。而Hashtable无论任何情况都会加锁所以也成就了强一致性。

并发编程实践中Coninrush currenttHashMap是一个经常被使用的数据结构，相比于Hashtable以及pareAndSwapXXX的方法这个方法是利用一个CAS算法实现无锁化的修改值的操作，他可以大大降低锁代理的性能消耗这个算法的基本思想就是不断地去比较当前内存中的变量值与你指定的一个变量值是否相等，如果相等则接受你指定的修改的值，否则拒绝你嘚操作因为当前线程中的值已经不是最新的值，你的修改很可能会覆盖掉其他线程修改的结果这一点与乐观锁，SVN的思想是比较类似的



我要回帖

更多关于 inrush current 的文章

 

随机推荐