HashMap 是使用频率最高的类型之一，同时也是面试经常被问到的问题之一，这是因为 HashMap 的知识点有很多，同时它又属于 Java 基础知识的一部分，因此在面试中经常被问到。
本课时的面试题是，HashMap 底层是如何实现的？在 JDK 1.8 中它都做了哪些优化？
典型回答
在 JDK 1.7 中 HashMap 是以数组加链表的形式组成的，JDK 1.8 之后新增了红黑树的组成结构，当链表大于 8 并且容量大于 64 时，链表结构会转换成红黑树结构，它的组成结构如下图所示：
数组中的元素我们称之为哈希桶，它的定义如下：
staticclassNode<K,V>implementsMap.Entry<K,V>{finalinthash;finalKkey;Vvalue;Node<K,V>next;
Node(inthash,Kkey,Vvalue,Node<K,V>next){
this.hash=hash;
this.key=key;
this.value=value;
this.next=next;
}
publicfinalKgetKey(){returnkey;}
publicfinalVgetValue(){returnvalue;}
publicfinalStringtoString(){returnkey+“=”+value;}
publicfinalinthashCode(){
returnObjects.hashCode(key)^Objects.hashCode(value);
}
publicfinalVsetValue(VnewValue){
VoldValue=value;
value=newValue;
returnoldValue;
}
publicfinalbooleanequals(Objecto){
if(o==this)
returntrue;
if(oinstanceofMap.Entry){
Map.Entry<?,?>e=(Map.Entry<?,?>)o;
if(Objects.equals(key,e.getKey())&&
Objects.equals(value,e.getValue()))
returntrue;
}
returnfalse;
}
}
可以看出每个哈希桶中包含了四个字段：hash、key、value、next，其中 next 表示链表的下一个节点。
JDK 1.8 之所以添加红黑树是因为一旦链表过长，会严重影响 HashMap 的性能，而红黑树具有快速增删改查的特点，这样就可以有效的解决链表过长时操作比较慢的问题。
考点分析
上面大体介绍了 HashMap 的组成结构，但面试官想要知道的远远不止这些，和 HashMap 相关的面试题还有以下几个：
JDK 1.8 HashMap 扩容时做了哪些优化？
加载因子为什么是 0.75？
当有哈希冲突时，HashMap 是如何查找并确认元素的？
HashMap 源码中有哪些重要的方法？
HashMap 是如何导致死循环的？
知识扩展
1.HashMap 源码分析
声明：本系列课程在未做特殊说明的情况下，都是以目前主流的 JDK 版本 1.8 为例来进行源码分析的。
HashMap 源码中包含了以下几个属性：
//HashMap初始化长度staticfinalintDEFAULT_INITIAL_CAPACITY=1<<4;//aka16
//HashMap最大长度
staticfinalintMAXIMUM_CAPACITY=1<<30;//1073741824
//默认的加载因子(扩容因子)
staticfinalfloatDEFAULT_LOAD_FACTOR=0.75f;
//当链表长度大于此值且容量大于64时
staticfinalintTREEIFY_THRESHOLD=8;
//转换链表的临界值，当元素小于此值时，会将红黑树结构转换成链表结构
staticfinalintUNTREEIFY_THRESHOLD=6;
//最小树容量
staticfinalintMIN_TREEIFY_CAPACITY=
什么是加载因子？加载因子为什么是 0.75？
加载因子也叫扩容因子或负载因子，用来判断什么时候进行扩容的，假如加载因子是 0.5，HashMap 的初始化容量是 16，那么当 HashMap 中有 16*0.5=8 个元素时，HashMap 就会进行扩容。
那加载因子为什么是 0.75 而不是 0.5 或者 1.0 呢？
这其实是出于容量和性能之间平衡的结果：
当加载因子设置比较大的时候，扩容的门槛就被提高了，扩容发生的频率比较低，占用的空间会比较小，但此时发生 Hash 冲突的几率就会提升，因此需要更复杂的数据结构来存储元素，这样对元素的操作时间就会增加，运行效率也会因此降低；
而当加载因子值比较小的时候，扩容的门槛会比较低，因此会占用更多的空间，此时元素的存储就比较稀疏，发生哈希冲突的可能性就比较小，因此操作性能会比较高。
所以综合了以上情况就取了一个 0.5 到 1.0 的平均数 0.75 作为加载因子。
HashMap 源码中三个重要方法：查询、新增和数据扩容。
先来看查询源码：
publicVget(Objectkey){Node<K,V>e;//对key进行哈希操作return(e=getNode(hash(key),key))==null?null:e.value;}finalNode<K,V>getNode(inthash,Objectkey){Node<K,V>[]tab;Node<K,V>first,e;intn;Kk;//非空判断if((tab=table)!=null&&(n=tab.length)>0&&(first=tab[(n-1)&hash])!=null){//判断第一个元素是否是要查询的元素if(first.hash==hash&&//alwayscheckfirstnode((k=first.key)==key||(key!=null&&key.equals(k))))returnfirst;//下一个节点非空判断if((e=first.next)!=null){//如果第一节点是树结构，则使用getTreeNode直接获取相应的数据if(firstinstanceofTreeNode)return((TreeNode<K,V>)first).getTreeNode(hash,key);do{//非树结构，循环节点判断//hash相等并且key相同，则返回此节点if(e.hash==hash&&((k=e.key)==key||(key!=null&&key.equals(k))))returne;}while((e=e.next)!=null);}}returnnull;}
从以上源码可以看出，当哈希冲突时我们需要通过判断 key 值是否相等，才能确认此元素是不是我们想要的元素。
HashMap 第二个重要方法：新增方法，源码如下：
publicVput(Kkey,Vvalue){//对key进行哈希操作returnputVal(hash(key),key,value,false,true);}finalVputVal(inthash,Kkey,Vvalue,booleanonlyIfAbsent,booleanevict){Node<K,V>[]tab;Node<K,V>p;intn,i;//哈希表为空则创建表if((tab=table)==null||(n=tab.length)==0)n=(tab=resize()).length;//根据key的哈希值计算出要插入的数组索引iif((p=tab[i=(n-1)&hash])==null)//如果table[i]等于null，则直接插入tab[i]=newNode(hash,key,value,null);else{Node<K,V>e;Kk;//如果key已经存在了，直接覆盖valueif(p.hash==hash&&((k=p.key)==key||(key!=null&&key.equals(k))))e=p;//如果key不存在，判断是否为红黑树elseif(pinstanceofTreeNode)//红黑树直接插入键值对e=((TreeNode<K,V>)p).putTreeVal(this,tab,hash,key,value);else{//为链表结构，循环准备插入for(intbinCount=0;;++binCount){//下一个元素为空时if((e=p.next)==null){p.next=newNode(hash,key,value,null);//转换为红黑树进行处理if(binCount>=TREEIFY_THRESHOLD-1)//-1for1sttreeifyBin(tab,hash);break;}//key已经存在直接覆盖valueif(e.hash==hash&&((k=e.key)==key||(key!=null&&key.equals(k))))break;p=e;}}if(e!=null){//existingmappingforkeyVoldValue=e.value;if(!onlyIfAbsent||oldValue==null)e.value=value;afterNodeAccess(e);returnoldValue;}}++modCount;//超过最大容量，扩容if(++size>threshold)resize();afterNodeInsertion(evict);returnnull;}
新增方法的执行流程，如下图所示：
HashMap 第三个重要的方法是扩容方法，源码如下：
finalNode<K,V>[]resize(){//扩容前的数组Node<K,V>[]oldTab=table;//扩容前的数组的大小和阈值intoldCap=(oldTab==null)?0:oldTab.length;intoldThr=threshold;//预定义新数组的大小和阈值intnewCap,newThr=0;if(oldCap>0){//超过最大值就不再扩容了if(oldCap>=MAXIMUM_CAPACITY){threshold=Integer.MAX_VALUE;returnoldTab;}//扩大容量为当前容量的两倍，但不能超过MAXIMUM_CAPACITYelseif((newCap=oldCap<<1)<MAXIMUM_CAPACITY&&oldCap>=DEFAULT_INITIAL_CAPACITY)newThr=oldThr<<1;//doublethreshold}//当前数组没有数据，使用初始化的值elseif(oldThr>0)//initialcapacitywasplacedinthresholdnewCap=oldThr;else{//zeroinitialthresholdsignifiesusingdefaults//如果初始化的值为0，则使用默认的初始化容量newCap=DEFAULT_INITIAL_CAPACITY;newThr=(int)(DEFAULT_LOAD_FACTOR*DEFAULT_INITIAL_CAPACITY);}//如果新的容量等于0if(newThr==0){floatft=(float)newCap*loadFactor;newThr=(newCap<MAXIMUM_CAPACITY&&ft<(float)MAXIMUM_CAPACITY?(int)ft:Integer.MAX_VALUE);}threshold=newThr;@SuppressWarnings({"rawtypes","unchecked"})Node<K,V>[]newTab=(Node<K,V>[])newNode[newCap];//开始扩容，将新的容量赋值给tabletable=newTab;//原数据不为空，将原数据复制到新table中if(oldTab!=null){//根据容量循环数组，复制非空元素到新tablefor(intj=0;j<oldCap;++j){Node<K,V>e;if((e=oldTab[j])!=null){oldTab[j]=null;//如果链表只有一个，则进行直接赋值if(e.next==null)newTab[e.hash&(newCap-1)]=e;elseif(einstanceofTreeNode)//红黑树相关的操作((TreeNode<K,V>)e).split(this,newTab,j,oldCap);else{//preserveorder//链表复制，JDK1.8扩容优化部分Node<K,V>loHead=null,loTail=null;Node<K,V>hiHead=null,hiTail=null;Node<K,V>next;do{next=e.next;//原索引if((e.hash&oldCap)==0){if(loTail==null)loHead=e;elseloTail.next=e;loTail=e;}//原索引+oldCapelse{if(hiTail==null)hiHead=e;elsehiTail.next=e;hiTail=e;}}while((e=next)!=null);//将原索引放到哈希桶中if(loTail!=null){loTail.next=null;newTab[j]=loHead;}//将原索引+oldCap放到哈希桶中if(hiTail!=null){hiTail.next=null;newTab[j+oldCap]=hiHead;}}}}}returnnewTab;}
从以上源码可以看出，JDK 1.8 在扩容时并没有像 JDK 1.7 那样，重新计算每个元素的哈希值，而是通过高位运算（e.hash & oldCap）来确定元素是否需要移动，比如 key1 的信息如下：
key1.hash = 10 0000 1010
oldCap = 16 0001 0000
使用 e.hash & oldCap 得到的结果，高一位为 0，当结果为 0 时表示元素在扩容时位置不会发生任何变化，而 key 2 信息如下：
key2.hash = 10 0001 0001
oldCap = 16 0001 0000
这时候得到的结果，高一位为 1，当结果为 1 时，表示元素在扩容时位置发生了变化，新的下标位置等于原下标位置 + 原数组长度，如下图所示：
其中红色的虚线图代表了扩容时元素移动的位置。
2.HashMap 死循环分析
以 JDK 1.7 为例，假设 HashMap 默认大小为 2，原本 HashMap 中有一个元素 key(5)，我们再使用两个线程：t1 添加元素 key(3)，t2 添加元素 key(7)，当元素 key(3) 和 key(7) 都添加到 HashMap 中之后，线程 t1 在执行到 Entry<K,V> next = e.next; 时，交出了 CPU 的使用权，源码如下：
voidtransfer(Entry[]newTable,booleanrehash){intnewCapacity=newTable.length;for(Entry<K,V>e:table){while(null!=e){Entry<K,V>next=e.next;//线程一执行此处if(rehash){e.hash=null==e.key?0:hash(e.key);}inti=indexFor(e.hash,newCapacity);e.next=newTable[i];newTable[i]=e;e=next;}}}
那么此时线程 t1 中的 e 指向了 key(3)，而 next 指向了 key(7) ；之后线程 t2 重新 rehash 之后链表的顺序被反转，链表的位置变成了 key(5) → key(7) → key(3)，其中 “→” 用来表示下一个元素。
当 t1 重新获得执行权之后，先执行 newTalbe[i] = e 把 key(3) 的 next 设置为 key(7)，而下次循环时查询到 key(7) 的 next 元素为 key(3)，于是就形成了 key(3) 和 key(7) 的循环引用，因此就导致了死循环的发生，如下图所示：
当然发生死循环的原因是 JDK 1.7 链表插入方式为首部倒序插入，这个问题在 JDK 1.8 得到了改善，变成了尾部正序插入。
有人曾经把这个问题反馈给了 Sun 公司，但 Sun 公司认为这不是一个问题，因为 HashMap 本身就是非线程安全的，如果要在多线程下，建议使用 ConcurrentHashMap 替代，但这个问题在面试中被问到的几率依然很大，所以在这里需要特别说明一下。
小结
本课时介绍了 HashMap 的底层数据结构，在 JDK 1.7 时 HashMap 是由数组和链表组成的，而 JDK 1.8 则新增了红黑树结构，当链表长度达到 8 并且容器达到 64 时会转换为红黑树存储，以提升元素的操作性能。同时还介绍了 HashMap 的三个重要方法，查询、添加和扩容，以及 JDK 1.7 resize() 在并发环境下导致死循环的原因。
精选评论
**路：
好好看看源码，当链表长度到8需要转化红黑树是还有一个判断table的length大于MIN_TREEIFY_CAPACITY，也就是64才会转化红黑树
*松：
hashMap负载因子选择0.75的原因，除了老师讲的两个原因，还有一点是不是因为，为了提升扩容效率，HashMap的容量（capacity）有一个固定的要求，那就是一定是2的幂。所以，如果负载因子是3/4的话，那么和capacity的乘积结果就可以是一个整数
讲师回复：
感谢补充。
*鑫：
1.HashMap采用链地址法，低十六位和高十六位异或以及hash&length-1来减少hash冲突
2.在1.7采用头插入，1.8优化为尾插入，因为头插入容易产生环形链表死循环问题 3.在1.7扩容位置为hash & 新容量-1，1.8是如果只有首节点那么跟1.7一样，否则判断是否为红黑树或者链表，再通过hash&原容量判断，为0放低位，否则高位，低位位置不变，高位位置=原位置+原容量 4.树化和退树化8和6的选择，红黑树平均查找为logn，长度为8时，查找长度为3，而链表平均为8除以2；当为6时，查找长度一样，而树化需要时间；然后中间就一个数防止频繁转换 5.容量设置为2的n次方主要是可以用位运算实现取模运算，位运算采用内存操作，且能解决负数问题；同时hash&length-1时，length-1为奇数的二进制都为1，index的结果就等同与hashcode后几位，只要hashcode均匀，那么hash碰撞就少 6.负载因子.75主要是太大容易造成hash冲突，太小浪费空间 希望顺便说下红黑树，自己看的时候有很多东西不太理解😶
讲师回复：
红黑树的知识，后面的章节有专门讲哈。
**辉：
这几天面试都背问到HashMap，确实很重要
**康：
链表转为红黑树那里，少了一个判断条件：hash桶的长度大于等于64。两个条件都满足才会转红黑树，不满足后者会直接调用扩容方法
讲师回复：
是需要满足两个条件，源码 treeifyBin() 里面有关于 MIN_TREEIFY_CAPACITY (64) 的判断。
*凯：
JDK 1.8 在扩容时并没有像 JDK 1.7 那样，重新计算每个元素的哈希值，而是通过高位运算（e.hash & oldCap）来确定元素是否需要移动 key1.hash = 10 0000 1010 oldCap = 16 0001 0000瞅了三次才明白这个16 0001 0000 什么含义。。。16 的二进制形式是0001 0000😥
**飞：
key1.hash = 10 0000 1010oldCap = 16 0001 0000这个简直看哭了我，一直在想最高位不是两个1吗，直到想到二进制只有01，才发现那是10和16
**磊：
说的不错，但是还是希望老师能够更新快点😁😁😁
编辑回复：
已反馈给讲师，后期会加快更新节凑
**可待：
当 t1 重新获得执行权之后，先执行 newTalbe[i] = e 把 key(3) 的 next 设置为 key(7)，这是为什么
讲师回复：
这里不是因果逻辑关系，重点讲的是极端情况下“这样执行”会导致问题的产生。
**告：
为什么到8变成红黑树，到6才退化成单链
讲师回复：
为了避免频发的触发类型转换带来的性能开销
**斌：
老师课很好理解，就是更新太慢了，只能干着急，哎
编辑回复：
已反馈给讲师，后期会加快更新节凑
**聪：
另外能不能更新再快一点哦，辛苦啦～
编辑回复：
已反馈给讲师，后期会加快更新节凑
**龙：
JDK8，扩容后链表不会反转吧
讲师回复：
不会的
*杰：
更新了第一名
*广：
当hashCode离散性很好的时候，树型bin用到的概率非常小，因为数据均匀分布在每个bin中，几乎不会有bin中链表长度会达到阈值（树华门槛）。但是在随机hashCode下，离散性可能会变差，然而JDK又不能阻止用户实现这种不好的hash算法，因此就可能导致不均匀的数据分布。不过理想情况下随机hashCode算法下所有bin中节点的分布频率会遵循泊松分布，我们可以看到，一个bin中链表长度达到8个元素的概率为0.00000006，几乎是不可能事件。所以，之所以选择8，不是拍拍屁股决定的，而是根据概率统计决定的。由此可见，发展30年的Java每一项改动和优化都是非常严谨和科学的。
christmad：
看到王磊老师在对第02讲评论回复时，有一段话“源码是这样判断的，可以理解为规定，0 不变，1变。就像井盖必须是圆的一样，那为什么不是方的一样，它总得有一个形状。”
这段话是不恰当的。
java hashmap 源码中扩容移动元素时，并不是随便定义 “0” 在原位，“1”要移动。 而是因为，这是经过计算后得到的规律。试想你扩容后进行查找， 对于某个元素 keyXXX来说扩容前和扩容后get 代码并没有任何改变，对这个 keyXXX 进行桶下标计算，必须能计算到正确的下标值才能找到存放的数据。
所以，这是有精确计算的，有规律的结果。原因可能是因为 hashmap 计算 idx 用了数组长度-1 作为掩码 并且 数组长度始终是 2的幂次方 两者结合作用造成的吧。这导致扩容时元素移动只有两种规律，一种待在 idx, 一种是移动到 idx+oldCap…不会移动到 idx+1 ,idx+2 这些位置去…
至于，为什么写 hashmap 源码的人知道这个规律，也许是人家数据结构算法和编程经验起作用了呢？
Hyolee：
课件可以下载吗？没更新的可以先发课件后补视频吗？
编辑回复：
关注拉勾教育公众号 咨询小助手获取课件。课件与课程同步更新的，不能提前放哈
**用户7139：
在讲死链问题时，t2 rehash是不是写错了？应该是resize吧？
讲师回复：
java 1.7 是 rehash 没写错哈。
*俊：
查缺补漏
**明：
今天的文章涉及的底层太深了。有很多数据结构和算法的知识。不是很懂。多看看
编辑回复：
加油哦，有不懂的地方可以留言提问哈
*胜：
HashMap 为什么选择 红黑树了，咋不用 AVL 树了。
讲师回复：
这个原因和二者的特性强相关，AVL树对平衡性要求更严格，比较适合查找密集型任务，它在查询上的优秀表现是以牺牲添加和删除的速度为代价的，所以显然红黑树更"中庸"通用性更好一些，所以Java中就使用了红黑树作为HashMap的底层实现了。
**凯：
if ((e.hash oldCap) == 0) { if (loTail == null) else } // 原索引 + oldCap else { if (hiTail == null) else }一个链表中的node的hash不是相等吗？e.hash oldCap处理得到的结果是一样吧？如果这样的话就不能在扩容之后移动元素。这个很困惑，麻烦老师给解答下🙏🙏
讲师回复：
这块是使用了一个比较巧妙的“算法”来确定数组在扩容之后要不要移动（0 表示不移动），其中 e.hash 表示旧数组中节点或元素 e 的 hash 值；而 oldCap 为旧数组的数组长度。
*坤：
加载因子过大，扩容发生频率较低，这个可以理解，但是为什么hash冲突的几率会增大呢？
讲师回复：
扩容发生频率低有限空间存储的元素就多了，发生 hash 冲突的几率也随之增大了。
**龙：
两个的结果，只有第三个部分，key1是0000、key2是0001不同，这个位置就叫"高一位"吗？
讲师回复：
是从后往前算的，前面的是高位 1 0000， 0 00001，高位就是最前面的 1 和 0，可以参考美团的这篇文章，它的图画的更详细一些：//06/24/java-hashmap.html
*飞：
在hashMap的putVal()方法里面最后有一个afterNodeInsertion(evict);方法，请问老师这个方法干嘛用的？
讲师回复：
afterNodeInsertion方法是为了继承HashMap的LinkedHashMap类使用的，LinkedHashMap中被覆盖的afterNodeInsertion方法，用来回调移除最早放入Map的对象。
*波：
1、加载因子越大，扩容频率减少，发生hash碰撞的机率增加；加载因子越小，扩容频率增加，发生hash碰撞的机率增加，这个结果是不是不太严谨呢，hash是跟容量挂钩的。2、扩容操作时，在1.8之后，只有当该索引处的元素的节点不为1时，才不会去重新计算元素的hash值；另外扩容操作是有new一个新的table出来的，当为链表时，只是将就原链表拆分为二，分别移动到新的table中，文中“通过高位运算(e.hasholdCap)来确定是否需要移动”这个说法是否存在不严谨的问题呢。望回复，谢谢～
讲师回复：
问题一描述没问题，扩容的频率决定了可用容量，可用容量的大小和发生碰撞的几率是成反比的，可用容量越大发生 hash 碰撞的几率就越小，发生扩容的频率越高空闲的容量也就越大，所以这个观点是成立的。问题二的高位运算是指在发生扩容之后的链表行为，所以描述也是 ok 的哈。
*以：
DEFAULT_INITIAL_CAPACITY这个是数组长度（哈希桶的默认大小值），还是说是数组加上链表的元素大小值
讲师回复：
这个是HashMap的数组默认长度，HashMap是由数组+链表（或红黑树）组成的哈，你看文中的数据结构图，其中哈希桶是放在数组中的哈。
**洪：
"通过高位运算（e.hash newCap，那就不需要移动，这种理解对吧？
讲师回复：
是的，通过高位运算结果判断是否要移动位置。
*浩：
新增方法流程图的左下角画错了吧，应该没有准备插入这一步，而是直接插入链表，然后判断大于8的话就转红黑树
讲师回复：
因为只有确定了 key 是否相等，才能判断是修改操作还是添加操作，如果是修改操作的话那直接赋值就可以了，就不用再去判断并新增元素了。
**4707：
hashmap中一开始赋值的与或运算感觉还是蛮重要的，比如 hashmap初始值给了1w，然后插入1w个值，问hashmap会不会扩容（答案是不会），因为一开始赋初值的时候如果不是2的幂数，则向上找最近的一个二的幂数，而且jdk8中hashmap用到的时候才实例化public HashMap() {
this.loadFactor = DEFAULT_LOAD_FACTOR; // all other fields defaulted
}
**波：
询问一下，负载因子选择0.75和泊松分布是否有关系
讲师回复：
坦率的说，我觉得没啥关联关系。
**_Android：
当加载因子设置比较大的时候，扩容的门槛就被提高了，扩容发生的频率比较低这句话的理解是不是说比如我把扩容因子设置为2 ，那么此时如果HashMap下一次扩容的时候需要的是2*16=32个长度的内存空间，那么老师解答一下这个这个内存分配机制，是否是这32个内存空间分配是否处于堆区分配，堆的优势就是动态分配内存大小，加载因子设置过大，会导致在堆区分配内存空间难度变大吗？如果是的话，扩容门槛变高，也就能够说得通了，继而扩容发生的概率降低也就是自然行得通。主要的问题还是没有明白扩容因子设置过大，导致的内存分配难度变大这个问题。麻烦解答一下，还有上诉猜想是否正确，比如是否在堆区分配扩容因子之后长度空间。也请解答一下，学习感觉还是要追求本质。
讲师回复：
可能表示的不是很清楚，“扩容因子设置过大，导致的内存分配难度变大这个问题”，这里的难度变大，不是指处理器的难度变大了，而是指业务场景的“难度变大了”，指的是扩容发生的门槛提高了，扩容的频率降低了。
**兵：
数组长度低于64的 即便是链表长度超过8也不会树化,而是扩容操作,数组超过64在链表大于等于8的时候才会进行树化吧?
讲师回复：
需要同时满足两个条件才行
**山：
老师这个面试题，是针对工作者，还是找工作的学生呀
编辑回复：
这些面试题在面试中经常会被考到，无论是工作者还是学生在面试前都应该吃透
**凯：
e.hash & oldCap 得到的结果，高一位为 0，当结果为 0 时表示元素在扩容时位置不会发生任何变化，为什么高位为0，在扩容的时候，位置就不会再变了？
讲师回复：
源码是这样判断的，可以理解为规定，0 不变，1变。就像井盖必须是圆的一样，那为什么不是方的一样，它总得有一个形状。
**文：
在resize()函数中，对于链表数组的遍历里面的又套了一个循环不太理解这里为什么要这样做，看起来是毫无意义的，除了做链表在数组中的移动以外没有看到其他的含义，老师能够解答一下吗？
讲师回复：
for (int j = 0; j < oldCap; ++j) { 吗？这个扩容之后把旧数据赋值给新容器
yhb：
更新的太慢了老师们，可以一周五更吗
编辑回复：
已反馈给讲师，后期会加快更新节凑
**盛：
最后transfer方法是在哪里执行的呢？
讲师回复：
JDK 1.7 resize(int newCapacity) 的时候会调用
**2132：
当加载因子设置比较大的时候，扩容的门槛就被提高了，扩容发生的频率比较低，占用的空间会比较小，但此时发生Hash冲突的几率就会提升，因此需要更复杂的数据结构来存储元素，这样对元素的操作时间就会增加。
老师您好，这一句我没懂，麻烦请解释下，谢谢。 1. 加载因子设置大， 发生Hash冲突的几率就会提升，是什么意思呢 2. 对于这种情况，需要更复杂的数据结构来存储，又如何理解
讲师回复：
加载因子设置的比较大，那么 Hash 扩容发生的频率就低了（门槛高了），数据存储的就更秘籍了，因此发生冲突的概率就高了。更复杂的数据结构指的是红黑树。
**杰：
个人认为只有当链表长度大于8而且哈希表的长度大于64时才会进行链表转化为红黑树的操作😀
讲师回复：
是这样，满足两个条件，还有 MIN_TREEIFY_CAPACITY (64) 的判断
**欧：
不错，能更新快点嘛
编辑回复：
已反馈给讲师，后期会加快更新节凑
xuezhiw：
希望作者更新快点哦……
编辑回复：
已反馈给讲师，后期会加快更新节凑
**芋：
老师您说的并发情况下是多线程访问同一个hashmap实例的情况吗？
讲师回复：
是的。
**7698：
点赞，然后来催更
编辑回复：
好哒，我们已反馈给讲师，后期会加快更新节凑
*华：
ConcurrentHashp是怎么实现的？感觉没讲完
讲师回复：
感谢反馈，篇幅有限，这篇重点讲解的是 HashMap。
**峰：
期待更优质的内容
**宏：
什么结果高一位，自己想的叫法吗？
讲师回复：
感谢反馈，中间少个逗号，“得到的结果，高一位为 0”
**聪：
不懂就问系列 2.HashMap 死循环分析 上面的那张图 绿色的方块指什么
讲师回复：
绿色表示高一位为 0，无需移动位置的元素。
**科：
总结的很到位
kyang：
扩容优化和死锁没有看懂。
编辑回复：
具体有什么不懂的问题可以留言提问哈
**1623：
我记得以前看源码发现链表转换红黑树应该会先去判断数组长度！当数组长度超过16后才会去把超过8的链表转红黑树吧！难道是我看错了？？
讲师回复：
数组长度 64 转为红黑树
**乐：
更新太慢了吧😓
编辑回复：
该课程每周三、五均有更新
