最详细HashMap底层详解(附常见面试题)
Map家族
先来看看HashMap在Map这个大家族中的位置。
这四种比较常见:HashMap , Hashtable , LinkedHashMap,TreeMap
HashMap存取速度快,它根据键的hashcode值存储数据,线程不安全,只有一个键允许为null,对值没有限制,对数据进行遍历的话读取的随机的。如果想要同步,可以用Collections的synchronizedMap方法使HashMap线程安全或者使用ConcurrentHashMap。
Hashtable和HashMap相似,但是线程安全,存取速度相对于Hashmap较慢,键和值都不能为null。Hashtable不建议在新代码中使用,不需要线程安全的场合可以用HashMap替换,需要线程安全的场合可以用ConcurrentHashMap替换。
LinkedHashMap是HashMap的子类,保存了数据存入的先后顺序,当用Iterator遍历的时候按照存入的先后顺序进行遍历。
TreeMap对键进行排列,当用Iterator遍历的时候默认按照键的升序进行。
哈希冲突
HashMap是使用哈希表来存储的。当我们要新增或查找某个元素,就把当前元素的关键字通过哈希函数映射到数组中的某个位置,通过数组下标一次定位就可完成操作。而哈希冲突就是两个不同的元素,通过哈希函数计算后得出的实际存储地址相同。或者说,当我们对某个元素进行哈希运算后得到一个存储地址,然而要进行插入的时候,发现已经被其他元素占用了,其实这就是所谓的哈希冲突。为解决冲突问题,可以采用开放地址法和链地址法等,在Java中HashMap采用了链地址法。链地址法,简单来说,就是数组加链表的结合。在每个数组中都一个链表结构,当数据被哈希函数计算后,就得到数组下标,把数据放在对应下标元素的数组中,如果数组中已经有元素,就转变为链表存在已存在的数据后面。哈希函数十分重要,好的哈希函数要把不同的键计算出来的结果十分分散的分布,分散的越均匀,发生Hash碰撞的概率就越小,map的存取效率就会越高,存储空间的利用率越好。
HashMap源码分析
HashMap的结构
HashMap的主干是一个Entry数组。Entry是HashMap的基本组成单元,每一个Entry包含一个key-value键值对。数组的长度一定是2的次幂。
//HashMap的主干数组,可以看到就是一个Entry数组,初始值为空数组{},主干数组的长度一定是2的次幂。 transient Entry<K,V>[] table = (Entry<K,V>[]) EMPTY_TABLE;
Entry是HashMap中的一个静态内部类。代码如下:
static class Entry<K,V> implements Map.Entry<K,V> { final K key; V value; Entry<K,V> next;//存储指向下一个Entry的引用,单链表结构 int hash;//对key的hashcode值进行hash运算后得到的值,存储在Entry,避免重复计算 /** * Creates new entry. */ Entry(int h, K k, V v, Entry<K,V> n) { value = v; next = n; key = k; hash = h; }
所以,HashMap的总体结构如下:
也就是说,HashMap = 数组(位桶) + 链表 , 数组是HashMap的主体,链表则是主要为了解决哈希冲突而存在的。当添加一个元素(key-value)时,就首先计算元素key的hash值,以此确定插入数组中的位置,但是可能存在同一hash值的元素已经被放在数组同一位置了,这时就添加到这个hash值对应的数组后面,但是形成了链表。同一各链表上的Hash值是相同的,所以说数组存放的是链表。在JDK1.8之后,当链表长度太长时(阈值为8),链表就转换为红黑树,这样大大提高了查找的效率,也就是HashMap = 数组(位桶) + 链表 + 红黑树。
初始化
执行构造函数,当我们看到这个new,第一反应应该是这货又在堆内存里开辟了一块空间。
Map<String,String> map = new HashMap<>();
空参构造函数:
public HashMap() { this.loadFactor = DEFAULT_LOAD_FACTOR; }
里面初始化了一个负载因子,值为0.75,负载因子乘上当前的容量等于阈值。HashMap有4个构造器,其他构造器如果用户没有传入initialCapacity 和loadFactor这两个参数,会使用默认值,以下是默认值:
////默认的桶数组大小 static final int DEFAULT_INITIAL_CAPACITY = 1 << 4; // aka 16 //极限值(超过这个值就将threshold修改为Integer.MAX_VALUE(此时桶大小已经是2的31次方了),表明不进行扩容了) static final int MAXIMUM_CAPACITY = 1 << 30; //负载因子 static final float DEFAULT_LOAD_FACTOR = 0.75f; // 从JDK1.8,当链表长度超过8就变为红黑树 static final int TREEIFY_THRESHOLD = 8; // 在哈希表扩容时,如果发现链表长度小于 6,则会由树重新退化为链表 static final int UNTREEIFY_THRESHOLD = 6; //在转变成树之前,还会有一次判断,只有键值对数量大于 64 才会发生转换。这是为了避免在哈希表建立初期,多个键值对恰好被放入了同一个链表中而导致不必要的转化 static final int MIN_TREEIFY_CAPACITY = 64;
这些参数对应的变量:
/**实际存储的key-value键值对的个数*/ transient int size; /**阈值,当table == {}时,该值为初始容量(初始容量默认为16);当table被填充了,也就是为table分配内存空间后, threshold一般为 capacity*loadFactory。HashMap在进行扩容时需要参考threshold,后面会详细谈到*/ int threshold; /**负载因子,代表了table的填充度有多少,默认是0.75 加载因子存在的原因,还是因为减缓哈希冲突,如果初始桶为16,等到满16个元素才扩容,某些桶里可能就有不止一个元素了。 所以加载因子默认为0.75,也就是说大小为16的HashMap,到了第13个元素,就会扩容成32。 */ final float loadFactor; /**HashMap被改变的次数,由于HashMap非线程安全,在对HashMap进行迭代时, 如果期间其他线程的参与导致HashMap的结构发生变化了(比如put,remove等操作), 需要抛出异常ConcurrentModificationException*/ transient int modCount;
其中一个构造方法:
public HashMap(int initialCapacity, float loadFactor) { //此处对传入的初始容量进行校验,最大不能超过MAXIMUM_CAPACITY = 1<<30(230) if (initialCapacity < 0) throw new IllegalArgumentException("Illegal initial capacity: " + initialCapacity); if (initialCapacity > MAXIMUM_CAPACITY) initialCapacity = MAXIMUM_CAPACITY; if (loadFactor <= 0 || Float.isNaN(loadFactor)) throw new IllegalArgumentException("Illegal load factor: " + loadFactor); this.loadFactor = loadFactor; threshold = initialCapacity; init();//init方法在HashMap中没有实际实现,不过在其子类如 linkedHashMap中就会有对应实现 }
从上面这段代码我们可以看出,在常规构造器中,没有为数组table分配内存空间(有一个入参为指定Map的构造器例外),而是在执行put操作的时候才真正构建table数组。
put存储数据
jdk1.7中的put方法:
public V put(K key, V value) { //如果table数组为空数组{},进行数组填充(为table分配实际内存空间),入参为threshold, //此时threshold为initialCapacity 默认是1<<4(24=16) if (table == EMPTY_TABLE) { inflateTable(threshold); } //如果key为null,存储位置为table[0]或table[0]的冲突链上 if (key == null) return putForNullKey(value); int hash = hash(key);//对key的hashcode进一步计算,确保散列均匀 int i = indexFor(hash, table.length);//获取在table中的实际位置 for (Entry<K,V> e = table[i]; e != null; e = e.next) { //如果该对应数据已存在,执行覆盖操作。用新value替换旧value,并返回旧value Object k; if (e.hash == hash && ((k = e.key) == key || key.equals(k))) { V oldValue = e.value; e.value = value; e.recordAccess(this); return oldValue; } } modCount++;//保证并发访问时,若HashMap内部结构发生变化,快速响应失败 //如果该对应数据为空,就在次数添加元素 addEntry(hash, key, value, i);//新增一个entry return null; }
inflateTable()这个方法为主干数组table分配存储空间,通过roundUpToPowerOf2(toSize)可以确保capacity为大于等于toSize的最接近toSize的二次幂,比如如果输入的toSize=13,那么capacity=16就是大于等于13的最接近的2的整数次幂;如果to_size=16,那么capacity就是16;如果to_size=17,那么capacity就是32。
jdk1.8中的put方法
1 public V put(K key, V value) { 2 // 对key的hashCode()做hash 3 return putVal(hash(key), key, value, false, true); 4 } 5 6 final V putVal(int hash, K key, V value, boolean onlyIfAbsent, 7 boolean evict) { 8 Node<K,V>[] tab; Node<K,V> p; int n, i; 9 // 步骤①:table为空则创建,触发resize方法 10 if ((tab = table) == null || (n = tab.length) == 0) 11 n = (tab = resize()).length; 12 // 步骤②:计算index,并对null做处理 13 if ((p = tab[i = (n - 1) & hash]) == null) 14 tab[i] = newNode(hash, key, value, null); 15 else { 16 Node<K,V> e; K k; 17 // 步骤③:节点key存在,直接覆盖value 18 if (p.hash == hash && 19 ((k = p.key) == key || (key != null && key.equals(k)))) 20 e = p; 21 // 步骤④:判断该链为红黑树 22 else if (p instanceof TreeNode) 23 e = ((TreeNode<K,V>)p).putTreeVal(this, tab, hash, key, value); 24 // 步骤⑤:该链为链表 25 else { 26 for (int binCount = 0; ; ++binCount) { 27 if ((e = p.next) == null) { //对于计算出的存储位置下标已经有数据,也就是冲突,转成链表存到下一位 28 p.next = newNode(hash, key,value,null); //链表长度大于8转换为红黑树进行处理 29 if (binCount >= TREEIFY_THRESHOLD - 1) // -1 for 1st 30 treeifyBin(tab, hash); 31 break; 32 } // key已经存在直接覆盖value 33 if (e.hash == hash && 34 ((k = e.key) == key || (key != null && key.equals(k)))) 35 break; 36 p = e; 37 } 38 } 39 40 if (e != null) { // existing mapping for key 41 V oldValue = e.value; 42 if (!onlyIfAbsent || oldValue == null) 43 e.value = value; 44 afterNodeAccess(e); 45 return oldValue; 46 } 47 } 48 ++modCount; 49 // 步骤⑥:超过最大容量就扩容,门限原本是初始容量*0.75 50 if (++size > threshold) 51 resize(); //扩原来的2倍 52 afterNodeInsertion(evict); 53 return null; 54 }
①.判断键值对数组table[i]是否为空或为null,如果为空,则执行resize()进行扩容,初始容量为16,扩展后是原来的2倍;
②.根据键值key计算hash值得到插入的数组索引i,如果table[i]==null,直接新建节点添加,转向⑥,如果table[i]不为空,转向③;
③.判断table[i]的首个元素是否和key一样,如果相同直接覆盖value,否则转向④,这里的相同指的是hashCode以及equals;
④.判断table[i] 是否为treeNode,即table[i] 是否是红黑树,如果是红黑树,则直接在树中插入键值对,否则转向⑤;
⑤.遍历table[i],判断链表长度是否大于8,大于8的话把链表转换为红黑树,在红黑树中执行插入操作,否则进行链表的插入操作;遍历过程中若发现key已经存在直接覆盖value即可;
⑥.插入成功后,判断实际存在的键值对数量size是否超多了最大容量threshold,如果超过,进行扩容。
存储地址的确定
使用hash函数对输出的键进行计算,得出一个值:
/**这是一个神奇的函数,用了很多的异或,移位等运算 对key的hashcode进一步进行计算以及二进制位的调整等来保证最终获取的存储位置尽量分布均匀*/ final int hash(Object k) { int h = hashSeed; if (0 != h && k instanceof String) { return sun.misc.Hashing.stringHash32((String) k); } h ^= k.hashCode(); h ^= (h >>> 20) ^ (h >>> 12); return h ^ (h >>> 7) ^ (h >>> 4); }
hash函数计算出的值,要再通过indexFor进一步处理来获取实际的存储位置:
//返回数组下标,实际的存储位置 static int indexFor(int h, int length) { return h & (length-1); //取模运算 }
对于任意给定的对象,只要它的hashCode()返回值相同,那么程序调用方法一所计算得到的Hash码值总是相同的。我们首先想到的就是把hash值对数组长度取模运算,这样一来,元素的分布相对来说是比较均匀的。但是,模运算的消耗还是比较大的,在HashMap中是这样做的:调用indexFor计算该对象应该保存在table数组的哪个索引处。
这个方法非常巧妙,它通过h & (table.length -1)来得到该对象的保存位,而HashMap底层数组的长度总是2的n次方,这是HashMap在速度上的优化。当length总是2的n次方时,h& (length-1)运算等价于对length取模,也就是h%length,但是&比%具有更高的效率。
扩容机制
JDK1.7与JDK1.8的扩容机制有所不同。
先看JDK1.7的代码,看什么时候需要扩容:
从JDK1.7的put方法中,当将要存储的数据经过计算存入的位置目前为空,就使用addEntry将数据存入:
//添加新的元素 void addEntry(int hash, K key, V value, int bucketIndex) { if ((size >= threshold) && (null != table[bucketIndex])) { //threshold为当前容量乘负载因子 resize(2 * table.length);//当size超过临界阈值threshold,并且即将发生哈希冲突时进行扩容 hash = (null != key) ? hash(key) : 0; bucketIndex = indexFor(hash, table.length); } createEntry(hash, key, value, bucketIndex); }
扩容条件:要判断是否到达阈值(负载因子*当前容量),同时是否产生哈希冲突。只有size超过临界阈值threshold,并且即将发生哈希冲突时进行扩容,扩容后再添加元素。扩容时调用resize()方法进行,数组长度变为两倍:
//扩容方法 1 void resize(int newCapacity) { //传入新的容量 2 Entry[] oldTable = table; //引用扩容前的Entry数组 3 int oldCapacity = oldTable.length; 4 if (oldCapacity == MAXIMUM_CAPACITY) { //扩容前的数组大小如果已经达到最大(2^30)了 5 threshold = Integer.MAX_VALUE; //修改阈值为int的最大值(2^31-1),这样以后就不会扩容了 6 return; 7 } 8 9 Entry[] newTable = new Entry[newCapacity]; //初始化一个新的Entry数组 10 transfer(newTable); //!!将数据转移到新的Entry数组里,数据迁移!! 11 table = newTable; //HashMap的table属性引用新的Entry数组 12 threshold = (int)(newCapacity * loadFactor);//修改阈值 13 }
resize()方法还调用了transfer()方法进行数据迁移,用来把原来的数据复制到新扩展的HashMap中,而这个函数也导致了HashMap的线程不安全:
//数据迁移的方法,头插法 void transfer(Entry[] newTable, boolean rehash) { int newCapacity = newTable.length; //for循环中的代码,逐个遍历链表,重新计算索引位置,将老数组数据复制到新数组中去(数组不存储实际数据,所以仅仅是拷贝引用而已) 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); } int i = indexFor(e.hash, newCapacity); //将当前entry的next链指向新的索引位置,newTable[i]有可能为空,有可能也是个entry链,如果是entry链,直接在链表头部插入。 e.next = newTable[i]; newTable[i] = e; e = next; } } }
transfer()方法将老数组中的数据逐个链表地遍历,扔到新的扩容后的数组中,我们的数组索引位置的计算是通过 对key值的hashcode进行hash扰乱运算后,再通过和 length-1进行位运算得到最终数组索引位置。
在JDK1.8 中的put方法中,先添加元素,判断添加后数组的容量超过阈值就直接扩容,和jdk的顺序不同。
JDK8的rehash过程很有趣,相比JDK7做了不少优化,我们来看下这里的rehash过程。
// 数组扩容为之前2倍大小的代码省略,这里主要分析rehash过程。 if (oldTab != null) { // 遍历旧数组 for (int j = 0; j < oldCap; ++j) { Node<K,V> e; if ((e = oldTab[j]) != null) { oldTab[j] = null; // 1. 如果旧数组中不存在碰撞,则直接移动到新数组的位置 if (e.next == null) newTab[e.hash & (newCap - 1)] = e; else if (e instanceof TreeNode) // 2. 如果存在碰撞,且节点类型是树节点,则进行树节点拆分(挂载到扩容后的数组中或者转为链表) ((TreeNode<K,V>)e).split(this, newTab, j, oldCap); else { // preserve order // 3. 处理冲突是链表的情况,会保留原有节点的顺序 Node<K,V> loHead = null, loTail = null; Node<K,V> hiHead = null, hiTail = null; Node<K,V> next; do { next = e.next; // 4. 判断扩容后元素是否在原有的位置(这里非常巧妙,下面会分析) if ((e.hash & oldCap) == 0) { if (loTail == null) loHead = e; else loTail.next = e; loTail = e; } // 5. 元素不是在原有位置 else { if (hiTail == null) hiHead = e; else hiTail.next = e; hiTail = e; } } while ((e = next) != null); // 6. 将扩容后未改变index的元素复制到新数组 if (loTail != null) { loTail.next = null; newTab[j] = loHead; } // 7. 将扩容后改变了index位置的元素复制到新数组 if (hiTail != null) { hiTail.next = null; // 8. index改变后,新的下标是j+oldCap,这里也很巧妙,下面会分析 newTab[j + oldCap] = hiHead; } } } } }
上面的代码中展现了整个rehash(扩容后,将原来数据迁移旧数据中药重新计算下标)的过程,先遍历旧数组中的元素,接着做下面的事情
如果旧数组中不存在数据碰撞(未挂载链表或者红黑树),那么直接将元素赋值到新数组中,其中index=e.hash & (newCap - 1)。
如果存在碰撞,且节点类型是树节点,则进行树节点拆分(挂载到扩容后的数组中或者转为链表)
如果存在碰撞,且节点是链表,则处理链表的情况,rehash过程会保留节点原始顺序(JDK7中不会保留,这也是导致jdk7中多线程出现死循环的原因)
判断元素在扩容后是否还处于原有的位置,这里通过(e.hash & oldCap) == 0判断,oldCap表示扩容前数组的大小。
发现元素不是在原有位置,更新hiTail和hiHead的指向关系
将扩容后未改变index的元素复制到新数组
将扩容后改变了index位置的元素复制到新数组,新数组的下标是 j + oldCap。
其中第4点和第5点中将链表的元素分为两部分(do…while部分),一部分是rehash后index未改变的元素,一部分是index被改变的元素。分别用两个指针来指向头尾节点。
比如当oldCap=8时,1–>9–>17都挂载在tab[1]上,而扩容后,1–>17挂载在tab[1]上,9挂载在tab[9]上。
那么是如何确定rehash后index是否被改变呢?改变之后的index又变成了多少呢?
这里的设计很是巧妙,还记得HashMap中数组大小是2的n次幂吗?当我们计算索引位置的时候,使用的是 e.hash & (table.length -1)。
这里我们讨论数组大小从8扩容到16的过程。
tab.length -1 = 7 0 0 1 1 1 e.hashCode = x 0 x x x x ============================== 0 0 y y y
扩容后,index的位置由低四位来决定,而低三位和扩容前一致。也就是说扩容后index的位置是否改变是由高字节来决定的,也就是说我们只需要将hashCode和高位进行运算即可得到index是否改变。
问题1:为何HashMap的初始容量以及后续容量必须是2的整数次幂?
如果初始化中传入的长度不是2的整数次幂,会初始化成距离传入数字最近的整数次幂。
还是看HashMap中put方法的部分源码:
// 步骤②:计算index,并对null做处理 if ((p = tab[i = (n - 1) & hash]) == null) tab[i] = newNode(hash, key, value, null);
以及indexFor()方法获取要存入数据的实际位置:
//返回数组下标,实际的存储位置 static int indexFor(int h, int length) { return h & (length-1); //取模运算 }
可以看出,向集合中添加元素时,会使用(n - 1) & hash的计算方法来得出该元素在集合中的位置;在HashMap扩容时调用resize()方法中的部分源码,可以看出会新建一个table,然后遍历旧的table,将旧的元素进过e.hash & (newCap - 1)的计算添加进新的tab中,也是(n - 1) & hash的计算方法,其中n是集合的容量,hash是添加的元素进过hash函数计算出来的hash值。
这个 h & (length-1) 至关重要 ,假如算出h的值是50,这个数组的容量目前是16,如果计算出来待存储数据的下标大于16怎么办,如何保证计算出的下标不会越界呢?最简单的问题就是用50除以16然后取余数(也叫取模。用%进行)作为下标,这个余数一定不会越界。但是在计算机中,取余的运算是十分的缓慢的。但是符号&是按位与的计算,这是位运算,计算机能直接运算,特别高效。当数组的长度 length 是2的n次幂时,其2进制表示为第一位是1,后面所有位都是0,length-1就是前面位是0,后面所有位都是1,类似于 00011***11这样的形式,这样与添加元素的hash值进行位运算时,与length-1也就是00011***11对应0的部分与的话是0,对应1的部分与的结果是它本身,与的结果最大一定是00011***11,最小结果都是0,正好是0到length-1,与数组的下标一一对应。计算出来正好是与数组的下标一一对应,这就是原因一。
再者,假设数组长度不取2的整数幂,而是一个奇数的话,那么length-1的最后一位是0,h与之相与后最后一位永远是0,导致数组下标是奇数的一直存不了数。假设数组的长度是一个偶数,但是不是2的整数幂,例如长度是10,那么length-1是9,对应2进制是1001,那么任意的数和它与的结果中,倒数第二位和第三位永远是0,这样还是有很多数组的角标被浪费。不会有空间的浪费,这就是原因二。
最后,当HashMap进行扩容时,容量扩展到原来的2倍,原来数组中的内容要迁移到扩展后的数组当中,那么迁移时就要计算每个值的新下标,假如扩容前的容量是8,对应length-1的2进制是0111,扩容后的容量是16,对应length-1的2进制是1111,那么在重新计算数组下标时:在扩容的数组中下标的后3位于原来数组相同,只有第一位可能不同。那么就只有两种情况:如果第一位也相同的话,那么迁移前后下标不变,如果第一位不同,那么迁移后下标加上扩容长度即可。扩容后数据迁移时,不需要重新计算hash,只判断其中一位即可,效率大大提高。
问题2 :HashMap为什么线程不安全?
HashMap的线程不安全主要体现在下面两个方面:
1.在JDK1.7中,当并发执行扩容操作时会造成环形链和数据丢失的情况。
2.在JDK1.8中,在并发执行put操作时会发生数据覆盖的情况。
在JDK1.7中,扩容数据时要进行把原数据迁移到新的位置,使用的方法:
//数据迁移的方法,头插法添加元素 void transfer(Entry[] newTable, boolean rehash) { int newCapacity = newTable.length; //for循环中的代码,逐个遍历链表,重新计算索引位置,将老数组数据复制到新数组中去(数组不存储实际数据,所以仅仅是拷贝引用而已) 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); } int i = indexFor(e.hash, newCapacity); //将当前entry的next链指向新的索引位置,newTable[i]有可能为空,有可能也是个entry链,如果是entry链,直接在链表头部插入。 e.next = newTable[i]; newTable[i] = e; e = next; } } }
这段代码是HashMap在JDK1.7的扩容操作,重新定位每个桶的下标,并采用头插法将元素迁移到新数组中。头插法会将链表的顺序翻转,这也是形成死循环的关键点。
当有两个线程时,假设线程1执行到 Entry<K,V> next = e.next 后,线程被挂起,此时e指向10,next 指向 2,e.next=null。接着线程2开始执行,直接执行完毕,扩容后的数组和上图中扩容后一样。此时再转为线程1执行,执行到e.next = newTable[i]时,线程1会把线程2的新表当成原始的hash表,将原来e指向的10节点当成是线程2中的10,放在自己所建table[0]的头节点,此时线程1的next仍然指向2,形成死循环。
对于JDK1.8当中,添加元素使用尾插法。如果对应角标是单向链表,将单向链表进行迁移,如果是红黑树,将双向链表进行数据迁移。
看一下下面这段JDK1.8中的put操作代码:
1 public V put(K key, V value) { 2 // 对key的hashCode()做hash 3 return putVal(hash(key), key, value, false, true); 4 } 5 6 final V putVal(int hash, K key, V value, boolean onlyIfAbsent, 7 boolean evict) { 8 Node<K,V>[] tab; Node<K,V> p; int n, i; 9 // 步骤①:table为空则创建,触发resize方法 10 if ((tab = table) == null || (n = tab.length) == 0) 11 n = (tab = resize()).length; 12 // 步骤②:计算index,并对null做处理 13 if ((p = tab[i = (n - 1) & hash]) == null) 14 tab[i] = newNode(hash, key, value, null); 15 else { 16 Node<K,V> e; K k; 17 // 步骤③:节点key存在,直接覆盖value 18 if (p.hash == hash && 19 ((k = p.key) == key || (key != null && key.equals(k)))) 20 e = p; 21 // 步骤④:判断该链为红黑树 22 else if (p instanceof TreeNode) 23 e = ((TreeNode<K,V>)p).putTreeVal(this, tab, hash, key, value); 24 // 步骤⑤:该链为链表 25 else { 26 for (int binCount = 0; ; ++binCount) { 27 if ((e = p.next) == null) { //对于计算出的存储位置下标已经有数据,也就是冲突,转成链表存到下一位 28 p.next = newNode(hash, key,value,null); //链表长度大于8转换为红黑树进行处理 29 if (binCount >= TREEIFY_THRESHOLD - 1) // -1 for 1st 30 treeifyBin(tab, hash); 31 break; 32 } // key已经存在直接覆盖value 33 if (e.hash == hash && 34 ((k = e.key) == key || (key != null && key.equals(k)))) 35 break; 36 p = e; 37 } 38 } 39 40 if (e != null) { // existing mapping for key 41 V oldValue = e.value; 42 if (!onlyIfAbsent || oldValue == null) 43 e.value = value; 44 afterNodeAccess(e); 45 return oldValue; 46 } 47 } 48 ++modCount; 49 // 步骤⑥:超过最大容量就扩容,门限原本是初始容量*0.75 50 if (++size > threshold) 51 resize(); //扩原来的2倍 52 afterNodeInsertion(evict); 53 return null; 54 }
其中第13行代码是判断是否出现hash碰撞,假设两个线程A、B都在进行put操作,并且hash函数计算出的插入下标是相同的,当线程A执行完第13行代码后由于时间片耗尽导致被挂起,而线程B得到时间片后在该下标处插入了元素,完成了正常的插入,然后线程A获得时间片,由于之前已经进行了hash碰撞的判断,所有此时不会再进行判断,而是直接进行插入,这就导致了线程B插入的数据被线程A覆盖了,从而线程不安全。
除此之前,还有就是代码的第50行处有个++size,我们这样想,还是线程A、B,这两个线程同时进行put操作时,假设当前HashMap的zise大小为10,当线程A执行到第50行代码时,从主内存中获得size的值为10后准备进行+1操作,但是由于时间片耗尽只好让出CPU,线程B快乐的拿到CPU还是从主内存中拿到size的值10进行+1操作,完成了put操作并将size=11写回主内存,然后线程A再次拿到CPU并继续执行(此时size的值仍为10),当执行完put操作后,还是将size=11写回内存,此时,线程A、B都执行了一次put操作,但是size的值只增加了1,所有说还是由于数据覆盖又导致了线程不安全。
3. 为什么负载因子设置为0.75,链表最长为8?
桶中元素个数和概率的对照表:
0: 0.60653066 1: 0.30326533 24000 2: 0.07581633 3: 0.01263606 4: 0.00157952 5: 0.00015795 6: 0.00001316 7: 0.00000094 8: 0.00000006 more: less than 1 in ten million
泊松分布
从上面的表中可以看到当桶中元素到达8个的时候,概率已经变得非常小,也就是说用0.75作为加载因子,每个碰撞位置的链表长度超过8个是几乎不可能的。
加载因子过高,例如为1,虽然减少了空间开销,提高了空间利用率,但同时也增加了查询时间成本;
加载因子过低,例如0.5,虽然可以减少查询时间成本,但是空间利用率很低,同时提高了rehash操作的次数。
选择0.75作为默认的加载因子,完全是时间和空间成本上寻求的一种折衷选择。
4. jdk8中对HashMap做了哪些改变?
- 在java 1.8中,如果链表的长度超过了8,那么链表将转换为红黑树。
- 发生hash碰撞时,java 1.7 会在链表的头部插入,而java 1.8会在链表的尾部插入
- 在java 1.8中,Entry被Node替代
5. 如果两个键的hashcode相同,你如何获取值对象?
找到bucket位置之后,会调用keys.equals()方法去找到链表中正确的节点,最终找到要找的值对象。
6.为什么String, Interger这样的wrapper类适合作为键?
String, Interger这样的wrapper类作为HashMap的键很常见,而且String最为常用。因为String是不可变的,也是final的,而且已经重写了equals()和hashCode()方法了。其他的wrapper类也有这个特点。不可变性是必要的,因为为了要计算hashCode(),就要防止键值改变,如果键值在放入时和获取时返回不同的hashcode的话,那么就不能从HashMap中找到你想要的对象。不可变性还有其他的优点如线程安全。如果你可以仅仅通过将某个field声明成final就能保证hashCode是不变的,那么请这么做吧。因为获取对象的时候要用到equals()和hashCode()方法,那么键对象正确的重写这两个方法是非常重要的。如果两个不相等的对象返回不同的hashcode的话,那么碰撞的几率就会小些,这样就能提高HashMap的性能。
程序员练习生 原创文章 190获赞 142访问量 10万+ 关注 私信- HashMap和HashTable底层原理以及常见面试题
- HashMap、ConcurentHashMap的原理与实现(持续补充)+ (一些常见面试题)
- 史上最全python面试题详解(一)(附带详细答案(关注、持续更新))
- 您可能不知道Java基础40道常见面试题及详细答案!
- 常见Android面试题及答案(详细整理)
- JSP, Servlet常见面试题详解
- Java集合 HashMap底层实现详解
- IT知名企业常见面试题实例与详解
- 【转载】Spring常见面试题总结(超详细回答)
- HashMap 常见面试题总结
- HashMap与LinkedHashMap底层存储原理详解
- HashMap底层实现原理详解(转载)
- HashMap和TreeMap区别详解以及底层实现
- Java技术_基础技术(0003)_类执行顺序详解+实例(阿里面试题)+详细讲解+流程图
- 常见Android面试题及答案(详细整理)
- HashMap深入理解详细分析原理以及常见面试问题
- 【JAVA面试题】Java工具包HashMap、ConcurrentHashMap、TreeMap底层实现与数据结构
- 常见Android面试题及答案(详细整理)
- 部分企业常见面试题详解
- IT知名企业常见面试题实例与详解