目录
HashMap是一个看似简单实而复杂的类,也是在面试中很容易问道的问题,哈哈哈,不怕……
众所周知,HashMap是一个用于存储Key-Value键值对的集合,每一个键值对也叫做Entry。这些个键值对(Entry)分散存储在一个数组当中,这个数组就是HashMap的主干
HashMap数组每一个元素的初始值都是Null
对于HashMap,我们最常使用的是两个方法:Get 和 Put
1、Put方法的原理
❓调用Put方法的时候发生了什么呢?
比如调用 hashMap.put("apple", 0) ,插入一个Key为“apple"的元素。这时候我们需要利用一个哈希函数来确定Entry的插入位置(index):
index = Hash(“apple”)
假定最后计算出的index是2,那么结果如下:
但是,因为HashMap的长度是有限的,当插入的Entry越来越多时,再完美的Hash函数也难免会出现index冲突的情况。比如下面这样:
这时候该怎么办呢?我们可以利用链表来解决。
HashMap数组的每一个元素不止是一个Entry对象,也是一个链表的头节点。每一个Entry对象通过Next指针指向它的下一个Entry节点。当新来的Entry映射到冲突的数组位置时,只需要插入到对应的链表即可:
需要注意的是,新来的Entry节点插入链表时,使用的是“头插法”。至于为什么不插入链表尾部,后面会有解释。
2、Get方法的原理
❓使用Get方法根据Key来查找Value的时候,发生了什么呢?
首先会把输入的Key做一次Hash映射,得到对应的index:
index = Hash(“apple”)
由于刚才所说的Hash冲突,同一个位置有可能匹配到多个Entry,这时候就需要顺着对应链表的头节点,一个一个向下来查找。假设我们要查找的Key是“apple”:
待查找Key:
第一步:我们查看的是头节点Entry6,Entry6的Key是banana,显然不是我们要找的结果
第二步:我们查看的是Next节点Entry1,Entry1的Key是apple,正是我们要找的结果
之所以把Entry6放在头节点,是因为HashMap的发明者认为,后插入的Entry被查找的可能性更大
3、高并发下的HashMap(jdk8以下版本)
在分析高并发场景之前,需要搞清楚【ReHash】
ReHash是HashMap在扩容时候的一个步骤
HashMap的容量是有限的。当经过多次元素插入,使得HashMap达到一定饱和度时,Key映射位置发生冲突的几率会逐渐提高。
这时候,HashMap需要扩展它的长度,也就是进行Resize
影响发生Resize的因素有两个:
1.Capacity
HashMap的当前长度。上一期曾经说过,HashMap的长度是2的幂。
2.LoadFactor
HashMap负载因子,默认值为0.75f。
衡量HashMap是否进行Resize的条件如下:
HashMap.Size >= Capacity * LoadFactor
HashMap的Resize()不是简单地把长度扩大,而是经过下面两步:
1.扩容
创建一个新的Entry空数组,长度是原数组的2倍。
2.ReHash
遍历原Entry数组,把所有的Entry重新Hash到新数组。为什么要重新Hash呢?因为长度扩大以后,Hash的规则也随之改变。
让我们回顾一下Hash公式:
index = HashCode(Key) & (Length - 1)
当原数组长度为8时,Hash运算是和111B做与运算;新数组长度为16,Hash运算是和1111B做与运算。Hash结果显然不同。
Resize前的HashMap:
Resize后的HashMap:
ReHash的Java代码如下
/**
* Transfers all entries from current table to newTable.
*/
void transfer(Entry[] newTable, boolean rehash) {
int newCapacity = 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);
}
int i = indexFor(e.hash, newCapacity);
e.next = newTable[i];
newTable[i] = e;
e = next;
}
}
}
上述流程在单线程下执行并没有问题,可惜HashMap并非线程安全
在多线环境中:(比较烧脑)
假设一个HashMap已经到了Resize的临界点。此时有两个线程A和B,在同一时刻对HashMap进行Put操作:
此时达到Resize条件,两个线程各自进行Rezie的第一步,也就是扩容:
线程A:
线程B:
原数组:
这时候,两个线程都走到了ReHash的步骤。让我们回顾一下ReHash的代码
假如此时线程B遍历到Entry3对象,刚执行完红框里的这行代码,线程就被挂起。对于线程B来说:
e = Entry3
next = Entry2
这时候线程A畅通无阻地进行着Rehash,当ReHash完成后,结果如下(图中的e和next,代表线程B的两个引用):
线程A:
线程B:
原数组:
直到这一步,看起来没什么毛病。接下来线程B恢复,继续执行属于它自己的ReHash。线程B刚才的状态是:
e = Entry3
next = Entry2
当执行到上面这一行时,显然 i = 3,因为刚才线程A对于Entry3的hash结果也是3。
我们继续执行到这两行,Entry3放入了线程B的数组下标为3的位置,并且e指向了Entry2。此时e和next的指向如下:
e = Entry2
next = Entry2
整体情况如图所示:
线程A:
线程B:
原数组:
接着是新一轮循环,又执行到红框内的代码行:
e = Entry2
next = Entry3
整体情况如图所示:
线程A:
线程B:
原数组:
接下来执行下面的三行,用头插法把Entry2插入到了线程B的数组的头结点:
整体情况如图所示:
线程A:
线程B:
原数组:
第三次循环开始,又执行到红框的代码:
e = Entry3
next = Entry3.next = null
最后一步,当我们执行下面这一行的时候,见证奇迹的时刻来临了
newTable[i] = Entry2
e = Entry3
Entry2.next = Entry3
Entry3.next = Entry2
链表出现了环形!
整体情况如图所示:
线程A:
线程B:
原数组:
此时,问题还没有直接产生。当调用Get查找一个不存在的Key,而这个Key的Hash结果恰好等于3的时候,由于位置3带有环形链表,所以程序将会进入死循环!
在高并发场景下,我们通常采用另一个集合类ConcurrentHashMap,这个集合类兼顾了线程安全和性能
1.Hashmap在插入元素过多的时候需要进行Resize,Resize的条件:
HashMap.Size >= Capacity * LoadFactor。
2.Hashmap的Resize包含扩容和ReHash两个步骤,ReHash在并发的情况下可能会形成链表环。
4、问题
❓HashMap的初始长度?
HashMap的默认初始长度是16,并且每次自动扩展或是手动初始化时长度必须是2的幂
为什么是16?——>>是为了服务从key映射到index的Hash算法
之前说过,从Key映射到HashMap数组的对应位置,会用到一个Hash函数:index = Hash(“apple”)
如何实现一个尽量均匀分布的Hash函数呢?我们通过利用Key的HashCode值来做位运算
如下公式(Length是HashMap的长度):index = HashCode(Key) & (Length - 1)
下面我们以值为“book”的Key来演示整个过程:
- 计算book的hashcode,结果为十进制的3029737,二进制的101110001110101110 1001。
- 假定HashMap长度是默认的16,计算Length-1的结果为十进制的15,二进制的1111。
- 把以上两个结果做与运算,101110001110101110 1001 & 1111 = 1001,十进制是9,所以 index=9。
可以说,Hash算法最终得到的index结果,完全取决于Key的Hashcode值的最后几位。
❓为什么长度必须是16或是2的幂?比如HashMap的长度是10会是怎么样的?
这样做不但效果上等同于取模,而且还大大提高了性能
假设HashMap的长度为10,重复刚才的运算步骤:
单独看这个结果,表面上并没有问题。我们再来尝试一个新的HashCode 101110001110101110 1011 :
让我们再换一个HashCode 101110001110101110 1111 试试 :
是的,虽然HashCode的倒数第二第三位从0变成了1,但是运算的结果都是1001。也就是说,当HashMap长度为10的时候,有些index结果的出现几率会更大,而有些index结果永远不会出现(比如0111)
这样,显然不符合Hash算法均匀分布的原则。
反观长度16或者其他2的幂,Length-1的值是所有二进制位全为1,这种情况下,index的结果等同于HashCode后几位的值。只要输入的HashCode本身分布均匀,Hash算法的结果就是均匀的
总结:
- 提高运算速度
- 增加散列度,降低冲突
- 减少内存碎片
Jdk1.8改进了HashMap,如果链表长度超过8,单链表自动转换红黑树以提高搜索效率和查询速度
❓Hashmap为什么线程不安全?(hash碰撞和扩容导致)
在并发插入元素时,HashMap扩容的时候可能会形成环形链表,让下一次读操作出现死循环。
非线程安全:
任一时刻可以由多个线程同时写HashMap,可能导致数据不一致
线程安全:
- 用Collections的SynchronizedMap()说的HashMap线程安全
- 使用ConcurrentHashMap
❓Hashmap中的key可以为任意对象或数据类型吗?
可以为null,但是不能为可变对象,如果是可变对象,对象中的属性改变,那么Hash也要进行相应的改变,导致下次五大找到已存在的Map中的数据