java.util.HashMap
是最常用的java容器类之一, 它是一个线程不安全的容器. 本文对JDK1.8.0中的HashMap实现源码进行分析.
HashMap
使用位运算巧妙的进行散列并使用链地址法处理冲突. 自JDK1.8后, 若表中某个位置元素数超过阈值 则会将其自动转换为红黑树来提高检索效率.
HashMap
中的迭代器同样采用fail-fast
机制, 即若迭代过程中容器发生结构性改变, 则会终止迭代.
HashMap
主要有三个视图接口keySet()
, values()
, entrySet()
. 它们都是基于迭代器实现的, 并不实际存储数据.
自JDK1.8.0开始HashMap使用静态内部类Node
来存储键值对结构, 不再使用Map.Entry
:
注意Node.next
使得Node可以形成单向链表结构. 再来看一下HashMap
中的主要字段:
HashMap
的底层数据结构是存储在table
域中的哈希表(Hash Table, 又称散列表). 哈希表是存储键值对的数组, 在查找元素时根据键的值计算出键值对在数组中的位置, 不需要扫描数组.
哈希表类似于词典, 可以通过词条快速地找出释义的位置, 不必从头开始逐个寻找. 哈希表访问元素的时间复杂度为O(1), 远高于普通数组的O(n)或树状结构的O(logn).
最简单的哈希函数自然是key.hashCode() % table.length
, 这就引出了哈希表固有的哈希冲突问题.
若table.length
为16, key1.hashCode()
为1202, key2.hashCode()
为3218. 那么,key1
和key2
的哈希值同为2, 但是table[2]
只能放置一个元素于是产生了哈希冲突.
哈希冲突问题主要从两方面考虑, 一是尽量减少哈希冲突的发生, 二是在哈希冲突发生后仍然正常工作.
HashMap根据Node.key
计算出Node
在table
数组中的位置, 但是并没有采用上文提及最简单的哈希函数:
hash函数的代码非常简练, 我们稍微改写一下:
关键的位运算h ^ (h >>> 16)
, 将32位整数h算术右移16位后与原值进行异或操作:
HashMap
中Node
在table
数组中的实际位置为(n - 1) & hash
. n为当前table.length
, HashMap
的扩容机制保证n为2的整数次幂, 因此(n - 1) & hash == hash % n
, 取n=16示例:
由于n一般较小, 当n < 65535时高16位为0. 若HashMap
采用key.hashCode() % n
来决定键值对的位置, 则hashCode()
的高16位对结果产生影响较小.
高16位很可能不参与运算意味着产生哈希冲突的可能性增大, 因此HashMap
先让高16位与低16位进行异或计算, 减少了哈希冲突的可能性.
在实践中无论使用什么哈希函数仍然存在冲突的可能性, 因此必须设计合适的机制在发生冲突后仍然能???正常工作. 常用的方法有开放地址法和链地址法.
使用开放地址法的哈希表每个位置只能放一个元素. 当发生哈希冲突时, 按照某种方法继续探测哈希表中的其他存储单元,直到找到空位置为止.
典型的如线性再散列: H = (e.hashCode + n) % table.length
, 其中n为再散列的次数, 即发生第1次冲突时需要再散列时n = 1
.
开放地址法的缺点在于再散列占据了哈希表中另一个位置, 增加了后续操作中发生哈希冲突的可能性.
HashMap
采用了另一种冲突解决方案 - 链地址法. 即哈希表中每个位置是一个链表, 允许放置多个元素. 发生哈希冲突时, 新元素只需添加到链表尾即可.
注意到Node.next
域可以让Node
连接为一个单链表, 即可使用链地址法解决哈希冲突.
若链表长度过长仍会造成查询效率降低, 在JDK1.8中的HashMap
实现中若某个位置链表长度达到阈值TREEIFY_THRESHOLD = 8
则会将链表变形为红黑树. 当删除元素使红黑树中元素数低于UNTREEIFY_THRESHOLD = 6
时会变回链表.
本文将在添加元素一节中详细介绍链地址法的实现.
与ArrayList
中的构造器类似, HashMap
的构造器只是计算并写入参数, 当第一次添加元素时才会实际分配存储空间:
三个构造器主要是设置initialCapacity
和loadFactor
参数. initialCapcity
是table
的初始大小; 当元素数达到threshold
时, HashMap
会执行扩容.
loadFactor
是影响threshold
的参数:threshold = table.length * loadFactor
. loadFactor
默认为0.75, 这是在空间利用率和执行效率之间比较平衡的取值.
int tableSizeFor(cap)
方法的返回值是大于cap的最小的2的整数幂. 注意到构造器只是设置了threshold
, 保证在初次扩容时达到initialCapacity
并没有实际分配存储空间.
首先阅读添加单个键值对的put
方法:
然后阅读进行扩容的resize
方法, HashMap
的扩容并不是简单地创建一个更大的table
并把原来的元素复制过去.
因为table.length
发生了变化, 所以哈希地址hash(key) % table.length
也会随之变化, 因此需要重新计算哈希地址. 除了保证正确索引外, 重新计算哈希值也可以将一个链表分散为多个较短的链表, 提高索引效率.
resize()
的扩容策略为2倍扩容, 因为原大小为2的整数次幂, 扩容后仍然保持该性质使基于位运算的哈希函数不会失效.
容量变为2倍使哈希地址增加了1位, 原来哈希地址相同的元素将会根据新增位的0-1取值被分散到两个两个地址中.
如当容量为16时, 5 % 16
, 21 % 16
得到的哈希地址均为5, 容量加倍后5 % 32 = 5; 21 % 32 = 21
. 注意到5的二进制表示00101
与21的二进制表示10101
仅有最高位不同.
计算最高位的取值非常简单, 若e.hashCode < oldCapacity
则最高位取0, 否则最高位取1. 因为 oldCapacity
是2的整数幂(二进制形式为1000...
), 所以可以用e.hashCode & oldCapacity = 0
代替e.hashCode < oldCapacity
.
HashMap
的实现采用了上述位运算策略将哈希表中的链表一分为二, 而避免重新计算哈希位置的开销.
批量添加元素的putAll(map)
方法通过map.entrySet
获得要添加的元素, 然后调用putVal
方法逐个添加元素.
在了解HashMap
的数据结构和添加元素策略之后, 查找元素的实现也不难理解:
删除元素同样考虑了单节点, 链表和树三种情况: