Jdk1.7HashMap如何扩容及解决死循环问题

上一篇 <<<Jdk1.7HashMap源码分析
下一篇 >>>JDK1.8HashMap源码分析


扩容原理

初始容量默认为16,负载因子默认为0.75,HashMap在扩容时,新数组的容量将是原来的2倍
负载因子越小,容易扩容,浪费空间,但查找效率高 链表特别短 减少hash冲突
负载因子越大,不易扩容,对空间的利用更加充分,查找效率低(链表拉长)hash冲突比较多,链表比较长
由于容量发生变化,原有的每个元素需要重新计算数组索引Index,再存放到新数组中去,这就是所谓的rehash。

扩容逻辑步骤

1、条件:map节点大小size>=阈值threshold,并且当前添加节点的数组下标已经存在数据的情况下才可以扩容
 (size >= threshold) && (null != table[bucketIndex])
2、新容量大小:旧容量的2倍
Entry[] newTable = new Entry[2*table.length];
3、遍历老数组,重新计算新的下标,并将数据设置到新数组中
for (Entry<K,V> e : table) {
   while(null != e) {
       Entry<K,V> next = e.next;
       //下标重新计算
       int i = indexFor(e.hash, newCapacity);
       e.next = newTable[i];
       newTable[i] = e;
       // 继续遍历下一个节点
       e = next;
   }
}
4、新数组设置为当前map的对象数组
   table = newTable;
5、阈值重新计算
threshold = (int)Math.min(newCapacity * loadFactor, MAXIMUM_CAPACITY + 1);

 为什么加载因子是0.75 而不是0.8或1 呢?
 加载因子越大,扩容的几率越小,空间的利用率会非常的高,但index下标冲突概率也就越大,每个下标里对应的链表数据会增多,查询效率会低下成本会增高。
 加载因子越小,index下标冲突概率也就越小,每个下标里的链表数据少,查询效率会提高,但反复扩容会导致扩容成本增大,未利用的空间也很多,空间的利用率不高
 因此,必须在 "冲突的机会"与"空间利用率"之间寻找一种平衡与折衷

扩容效果

扩容产生死循环的问题说明

jdk8已解决了该问题

原理分析:当在多线程的情况下,同时对hashMap实现扩容,因为每次数组在扩容的时候,新的数组长度发生了变化,需要重新计算index值;需要将原来的table中的数据移动到新的table中,在hashMap1.7版本598行 e.next=newTable[i];直接改变了原来的next关系,导致出现脏读的数据。
e.next=newTable[i]; 目的获取当前index在新table中是否存在index冲突问题。
如何解决:同步锁或使用concurrentMap解决。

 
  假设链表数据有:A.next=B
 
  第一次:
  a、next = e.next;
  e = A
  next = B
 
  b、i = indexFor(e.hash, newCapacity);
  假设i=2
 
  c、e.next = newTable[i];
  由于newTable[i]的值为null,也就是A.next = null
 
  d、newTable[i] = e;
  A填充到新table中
 
  第二次:
  a、next = e.next;
  e = B
  next = null
 
  b、i = indexFor(e.hash, newCapacity);
  假设i也为2
 
  c、e.next = newTable[i];
  由于newTable[i]的值为A,此时变为了B.next = A
 
  d、newTable[i] = e;
  B填充到新table中
 
  总结:
  1、扩容后,结构顺序倒了,原有A.next=B变成了B.next=A
  2、如果多线程同时在扩容,由于A和B节点是共用的,会导致遍历了A后获取B时,B.next=A,就会出现了死循环的情况。

相关文章链接:
<<<Java集合类图总览
<<<ArrayList的添加和删除操作实现原理图解
<<<ArrayList的动态扩容、ModCount及fail-fast原理
<<<LinkedList增删改查操作底层实现原理
<<<数组拷贝的几种方式及和链表结构的对比
<<<Jdk1.7HashMap源码分析
<<<JDK1.8HashMap源码分析
<<<ConcurrentHashMap在JDK1.8版本比1.7改进了什么
<<<JDK8的HashMap中红黑树左旋右旋原理图解
<<<基于LinkedHashMap手写LRU淘汰策略
<<<HashSet集合底层实现原理
<<<HashTable底层实现原理及和ConcurrentHashMap区别
<<<java集合常见面试题

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 218,284评论 6 506
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 93,115评论 3 395
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 164,614评论 0 354
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 58,671评论 1 293
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 67,699评论 6 392
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 51,562评论 1 305
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 40,309评论 3 418
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 39,223评论 0 276
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 45,668评论 1 314
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 37,859评论 3 336
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 39,981评论 1 348
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 35,705评论 5 347
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 41,310评论 3 330
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 31,904评论 0 22
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 33,023评论 1 270
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 48,146评论 3 370
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 44,933评论 2 355

推荐阅读更多精彩内容