【有料】HashMap之resize详解

daobuxinzi

已于 2023-04-26 17:29:42 修改

阅读量493

点赞数 1

文章标签：哈希算法算法 java

于 2023-04-26 17:29:25 首次发布

原文链接：https://zhuanlan.zhihu.com/p/55890890

版权

1. 导读

上期分享了HashMap的key定位以及数据节点的设计, 本期就下面三个问题来分享下个人对于HashMap扩容的理解:

.1 HashMap为什么要扩容? 何时扩容?

.2 负载因子为什么是0.75?

.3 HashMap如何扩容;

2. HashMap为什么要扩容

经过上期分享, 我们都知道HashMap在构建初始是可以指定table(hash槽)的长度的, 假设我们设定了2, 这时候有10万数据要插入, 最好的情况就是两边各是5万, 最差的情况就是一边是10万, 显然这个时候hash冲突已经很严重了, 为了解决冲突, 我们就需要对table进行扩容, 所以HashMap的扩容就是加长table的长度, 来减少hash冲突的概率;

3. HashMap何时扩容

HashMap是如何来判定何时该扩容的呢?

 final V putVal(int hash, K key, V value, boolean onlyIfAbsent, boolean evict) {
 if ((tab = table) == null || (n = tab.length) == 0)
			 n = (tab = resize()).length;
		...
		if (++size > threshold)
			resize();
		...
	}

上面代码是HashMap::put的核心实现, 我将与本问题无关的代码都省略了, HashMap会在两个地方进行resize(扩容):

.1 HashMap实行了懒加载, 新建HashMap时不会对table进行赋值, 而是到第一次插入时, 进行resize时构建table;

.2 当HashMap.size 大于 threshold时, 会进行resize;threshold的值我们在上一次分享中提到过: 当第一次构建时, 如果没有指定HashMap.table的初始长度, 就用默认值16, 否则就是指定的值; 然后不管是第一次构建还是后续扩容, threshold = table.length * loadFactor;

3. 为什么是0.75

HashMap的扩容时取决于threshold, 而threshold取决于loadFactor, loadFactor(负载因子)HashMap的默认值是0.75(3/4), 那么为什么当HashMap的容量超过3/4时就需要扩容了呢? 为什么不是1/2扩容或者等于table.length时扩容呢?

答案就在HashMap的注释中:

 /**
	 * Ideally, under random hashCodes, the frequency of
	 * 	nodes in bins follows a Poisson distribution
	 * (http://en.wikipedia.org/wiki/Poisson_distribution) with a
	 * 	parameter of about 0.5 on average for the default resizing
	 * 	threshold of 0.75, although with a large variance because of
	 * 	resizing granularity. Ignoring variance, the expected
	 * 	occurrences of list size k are (exp(-0.5) * pow(0.5, k) /
	 * 	factorial(k)). The first values are:
	 *
	 * 0: 0.60653066
	 * 1: 0.30326533
	 * 2: 0.07581633
	 * 3: 0.01263606
	 * 4: 0.00157952
	 * 5: 0.00015795
	 * 6: 0.00001316
	 * 7: 0.00000094
	 * 8: 0.00000006
	 * 
	 */

根据统计学的结果, hash冲突是符合泊松分布的, 而冲突概率最小的是在7-8之间, 都小于百万分之一了; 所以HashMap.loadFactor选取只要在7-8之间的任意值即可, 但是为什么就选了3/4这个值, 我们看了HashMap的扩容机制也就知道了;

4. HashMap如何扩容

因为扩容的代码比较长, 我用文字来叙述下HashMap扩容的过程:

.1 如果table == null, 则为HashMap的初始化, 生成空table返回即可;

.2 如果table不为空, 需要重新计算table的长度, newLength = oldLength << 1(注, 如果原oldLength已经到了上限, 则newLength = oldLength);

.3 遍历oldTable:

.3.2 首节点为空, 本次循环结束;

.3.1 无后续节点, 重新计算hash位, 本次循环结束;

.3.2 当前是红黑树, 走红黑树的重定位;

.3.3 当前是链表, JAVA7时还需要重新计算hash位, 但是JAVA8做了优化, 通过(e.hash & oldCap) == 0来判断是否需要移位; 如果为真则在原位不动, 否则则需要移动到当前hash槽位 + oldCap的位置;

HashMap::resize的核心就是上图, 链表与红黑树的resize过程大同小异: 红黑树是把构建新链表的过程变为构建两颗新的红黑树, 定位table中的index都是用的 e.hash & oldCap == 0 来判断;

再来看下 e.hash & oldCap == 0为什么可以判断当前节点是否需要移位, 而不是再次计算hash;

仍然是原始长度为16举例:

 old:
 10: 0000 1010
 15: 0000 1111
 &: 0000 1010 
 
 new:
 10: 0000 1010
 31: 0001 1111
 &: 0001 1010

从上面的示例可以很轻易的看出, 两次indexFor()的差别只是第二次参与位于比第一次左边有一位从0变为1, 而这个变化的1刚好是oldCap, 那么只需要判断原key的hash这个位上是否为1: 若是1, 则需要移动至oldCap + i的槽位, 若为0, 则不需要移动;

这也是HashMap的长度必须保证是2的倍数的原因, 正因为这种环环相扣的设计, HashMap.loadFactor的选值是3/4就能理解了, table.length * 3/4可以被优化为(table.length >> 2) << 2) - (table.length >> 2) == table.length - (table.lenght >> 2), JAVA的位运算比乘除的效率更高, 所以取3/4在保证hash冲突小的情况下兼顾了效率;

5. JDK8对JDK7的优化

 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;
 }
 }
 }

上面的代码是JAVA7中对于HashMap节点重新定位的代码, 我们都知道HashMap是非线程安全的, 最主要的原因是他在resize的时候会形成环形链表, 然后导致get时死循环;

resize前的HashMap如下图所示: