HashMap之resize详解

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如下图所示:

这时候有两个线程需要插入第四个节点, 这个时候HashMap就需要做resize了,我们先假设线程已经resize完成, 而线程二必须等线程一完成再resize:

经过线程一resize后, 可以发现a b节点的顺序被反转了, 这时候我们来看线程二:

.1 线程二的开始点是只获取到A节点, 还没获取他的next;
.2 这时候线程一resize完成, a.next = null; b.next = a; newTable[i] = b;
.3 线程二开始执行, 获取A节点的next节点, a.next = null;
.4 接着执行 a.next = newTable[i]; 因为这时候newTable[i]已经是B节点了, 并且b.next = a; 那么我们把newTablei赋值给a.next后, 就会线程a-b-a这样的环形链表了, 也就是上图的结果;
.5 因为第三步的a.next已经是null, 所以C节点就丢失了;
.6 那这时候来查位于1节点的数据D(其实不存在), 因为 d != a, 会接着查a.next, 也就是b; 但是b != d, 所以接着查b.next, 但是b.next还是a; 这就悲剧了, 在循环里出不去了;
这就是JDK7resize最大的缺陷, 会形成死循环;
那么JDK8做了优化以后, 死循环的问题解除了吗?

通过上图我们发现JDK8的resize是让节点的顺序发生改变的, 也就是没有倒排问题了;也是假设有两个线程, 线程一已执行完成, 这时候线程二来执行:
.1 因为顺序没变, 所以node1.next还是node2, 只是node2.next从node3变成了null;
.2 而且JDK8是在遍历完所有节点之后, 才对形成的两个链表进行关联table的, 所以不会像JAVA7一般形成A-B-A问题了;
.3 但是如果并发了, JAVA的HashMap还是没有解决丢数据的问题, 但是不和JAVA7一般有数据倒排以及死循环的问题了;

HashMap设计时就是没有保证线程安全的, 所以在多线程环境请使用ConcurrentHashMap;

以上就是本期分享的全部内容了, 如果对于HashMap::resize还有其他问题, 欢迎留言交流;
如果我的分享对你有帮助, 烦请点赞转发, 感谢;