HashMap面试知识点总结:
1.数据结构中的HashMap?能跟我聊聊他的结构和底层原理么?
-
首先在java1.8以前用的是单纯的数组加链表的结构,进入Java1.8以后就是用数组+链表+红黑树的数据结构
- 加入红黑树的与原因:1.8以前的HashMap中使用的是数组+链表,但是由于哈希函数不可能百分百让元素均匀分布,这就会造成HashMap中有大量的元素会存入同一个index(桶)下,这样index就有一条长链表,这时候HashMap进行插入和取出的时候,遍历链表就会使得遍历的时间复杂度为O(n),失去了HashMap的优势;但是,在1.8以后就加入了红黑树(查找的时间复杂度变成了O(logn)),实现优化。
-
java1.8以后每个数组中的键值对叫做Node,每个节点都会存储hash、key、value+下一个节点
-
**插入原理(简单步骤):**当我们put插入的时候就会根据key的hash计算一个index的值,再根据index的值将数据插入节点中。
-
链表的作用(加入链表的作用):两个不同的元素,通过哈希函数得到的实际存储地址是可能相同的,所以就有了链表应对哈希冲突(碰撞)
-
插入的方法(对比及原因):
-
java8之前是头插法, 就是说新来的值会取代原有的值,原有的值就顺推到链表中去,如上图。在java8以后就换成了尾插法。
- 1.为什么要换成尾插法呢?:了解这个就必须先了解resize(扩容)的机制
-
-
-
1.1怎么进行resize:
- 1-HashMap的初始默认容量是2^4=16(Capacity)和负载因子0.75f(LoadFactor)是两个重要的因素。Capacity*LoadFactor=阈值
- 2-就是当数组中存储元素量(不是整体元素个数而是数组的元素个数)达到阈值是,就会进行resize
- 3-扩容分两步:一:创建一个新的entry空数组,长度是原来的两倍;二:rehash–>遍历原数组,把所有的entry重新进行hash运算到新数组中
- **为什么要rehash:**因为Hash的运算规则是–> index = HashCode(Key) & (Length - 1) ,由于新的数组长度发生了变化,那么就得重新hash计算键值对新的位置。
- 1-HashMap的初始默认容量是2^4=16(Capacity)和负载因子0.75f(LoadFactor)是两个重要的因素。Capacity*LoadFactor=阈值
-
**2.为什么头插法会造成死循环以及尾插法不会:**参考我的另一篇解释: https://blog.csdn.net/stxsysxj/article/details/104804920
- 3.是不是Java8就可以把HashMap用在多线程中呢?:- 也不是,因为put/get方法都没有加同步锁依旧有可能造成脏读,所以多线程还是用ConcurrentHashMap,比较直接在方法上上锁的HashTable, 一次性锁住整个hash表,并发度很低,最多同时允许一个线程访问 ,效率低下.
- ConcurrentHashMap:使用锁分离技术,一次锁住一个桶。- ConcurrentHashMap默认将hash表分为16个桶,诸如get、put、remove等常用操作只锁住当前需要用到的桶。这样,原来只能一个线程进入,现在却能同时有16个写线程执行,并发性能的提升是显而易见的。
- 当需要操作整个表的时候,就会按顺序锁定所有段,操作完毕后,又按顺序释放所有段的锁 - 参考文章: https://www.cnblogs.com/heyonggang/p/9112731.html
- ConcurrentHashMap默认将hash表分为16个桶,诸如get、put、remove等常用操作只锁住当前需要用到的桶。这样,原来只能一个线程进入,现在却能同时有16个写线程执行,并发性能的提升是显而易见的。
- 也不是,因为put/get方法都没有加同步锁依旧有可能造成脏读,所以多线程还是用ConcurrentHashMap,比较直接在方法上上锁的HashTable, 一次性锁住整个hash表,并发度很低,最多同时允许一个线程访问 ,效率低下.
2.HashMap的主要参数:
-
1.默认初始容量:16,必须是2的整数次方
-
为什么是16,是2的整数次方?
-
1.index = HashCode(Key) & (Length - 1)这是index的计算方法,进行这样计算的原因是为了能够让index的hash值分布均匀
-
初始化时16,length-1就是15–>二进制为1111,这样再进行位与运算就是把hash(key)的最后四位当作index的hash值,这样能够有效的降低hash碰撞
-
hash的计算规则是
static final int hash(Object key) { int h; return (key == null) ? 0 : (h = key.hashCode()) ^ (h >>> 16); }
-
为了将hash(key)分布的更加均匀,就将元素的初始hash值和这个值右移的16位结果进行异或运算,让高低16位能够混合决定index的hash值,分布均匀,降低碰撞.
-
参考文章: https://blog.csdn.net/u011240877/article/details/53351188
-
-
为什么是2的整数次方:
- 首先2^N是偶数,这样length-1就是奇数,这样最后一位就是1,进行位与运算就能够保证hash(key)的最后一位可以是0或者1,即index可能是偶数或者奇数,分布均匀
- 参考文章: https://github.com/GeniusVJR/LearningNotes/blob/master/Part2/JavaSE/HashMap%E6%BA%90%E7%A0%81%E5%89%96%E6%9E%90.md
-
-
-
2.默认加载因子0.75
-
3.阈值:容量*加载因子
-
4.树形阈值:默认8;当bucket中的链表长度大于8,则进行链表树化。
-
5.非树形阈值:默认6;当进行扩容时, 当在扩容(resize())时(此时HashMap的数据存储位置会重新计算),在重新计算存储位置后,当原有的红黑树内数量 < 6时,则将 红黑树转换成链表
-
6.树形最小容量:桶可能是树的哈希表的最小容量。至少是 TREEIFY_THRESHOLD 的 4 倍,这样能避免扩容时的冲突
//链表转红黑树的阈值 static final int TREEIFY_THRESHOLD = 8; //红黑树转链表的阈值 static final int UNTREEIFY_THRESHOLD = 6; /** *最小树形化容量阈值:即 当哈希表中的容量 > 该值时,才允许树形化链表 (即 将链表 转换成红黑树) *否则,若桶内元素太多时,则直接扩容,而不是树形化 *为了避免进行扩容、树形化选择的冲突,这个值不能小于 4 * TREEIFY_THRESHOLD **/ static final int MIN_TREEIFY_CAPACITY = 64;
- 前两个没什么问题,但是第三个变量: 只有在数组长度大于64的时候,才能树形化列表
- 链表长度大于8的时候就会调用treeifyBin方法转化为红黑树,但是在treeifyBin方法内部却有一个判断,当只有数组长度>64的时候,才会进行树形化,否则就只是resize扩容。
- 因为链表过长而数组过短,会经常发生hash碰撞,这个时候树形化其实是治标不治本,因为引起链表过长的根本原因是数组过短。执行树形化之前,会先检查数组长度,如果长度小于<64,则对数组进行扩容,而不是进行树形化。
- 所以在数组长度没有超过最小树形化容量阈值:64时,发生的扩容是:
- 超过数组阈值
- 链表长度超过8,但是数组长度不足64,依旧不会发生树形化,而是进行resize后rehash重新排列
- 参考文章: https://blog.csdn.net/qq_33945246/article/details/103925048 :<hashmap 的扩容和树形化>
3.为什么我们在重写equals方法的时候要重写hashcode方法?
-
因为在java中,所有的对象都是继承于Object类。Ojbect类中有两个方法equals、hashCode,这两个方法都是用来比较两个对象是否相等的。
在未重写equals方法我们是继承了object的equals方法,那里的 equals是比较两个对象的内存地址,显然我们new了2个对象内存地址肯定不一样
- 对于值对象,==比较的是两个对象的值
- 对于引用对象,比较的是两个对象的地址
-
如果我们只重写equals方法,那么在对key值进行hash时,由于对象的地址不同,属性相同,那么hash方法返回的hash值还是不同,所以我们要重写hash(), 以保证相同的对象返回相同的hash值,不同的对象返回不同的hash值。
4.HashMap的put方法原理:
图片来源:http://tech.meituan.com/java-hashmap.html