JDK1.6中的HashMap扩容

JDK1.6中的HashMap扩容

说在前边

JDK1.8之前的HashMap采用数组加链表的方式存储数据。因为手头暂时找不到JDK1.7的源码包，而在1.8之前1.6和1.7的HashMap源码并没有太大的不同，就用1.6代替吧。

扩容简介

HashMap是会在放入新元素后根据元素的总个数与当前数组长度之间的关系动态调整数组长度进行扩容操作的（仿佛是在放屁一样的废话）。这个元素个数与数组长度的关系在代码里被定义为threshold，它由数组的长度与负载因子loadFactor相乘得出（也可手动设置）。数组的长度被定义为capacity。在JDK1.8之前，每次放入新元素会判断当前元素总个数是否大于等于threshold，如果成立则进行扩容操作，而在JDK1.8之后这个判断条件则变成了当前元素总个数是否大于（没有等于了）threshold，成立则进行扩容。代码如下（第一段为1.6源码，第二段为1.8源码）

void addEntry(int hash, K key, V value, int bucketIndex) {
	Entry<K,V> e = table[bucketIndex];
        table[bucketIndex] = new Entry<K,V>(hash, key, value, e);
    // 1.6中的判断条件为大于等于
        if (size++ >= threshold)
            resize(2 * table.length);
    }

 final V putVal(int hash, K key, V value, boolean onlyIfAbsent,
                   boolean evict) {
        /** 删除部分代码 */
        ++modCount;
     // 1.8 中判断条件为大于没有等于了（ps: 1.8的源码真的是复杂了不只亿点点，心疼我所剩无几的头发）
        if (++size > threshold)
            resize();
        afterNodeInsertion(evict);
        return null;
    }

知道了扩容的大致条件，就要知道扩容具体要做哪些事了。(感觉说出来也是像放屁一样的废话，，)动一动我不发达的脑子就能想出来要做的就两件事：

• 第一件是把数组大小变大，在1.8的源码里是通过将原大小左移一位扩大为原来的两倍（面试题没少背到这个玩意儿吧。。），1.6里边则是直接暴力地乘了一个2

• 第二件事就是把原来的数据原封不动的复制过去，同时要保证复制完成之后的数据在结构上仍然保持不变（这也是个屁话，而且在实际操作中只是保证了相对关系没变，顺序实际上翻了个个儿）

要做到第一件事很简单，new一个新的数组把引用传回去就ok，第二件事就是这篇水文的主要内容了。

扩容过程

在JDK1.6中主要通过resize()和transfer()两个方法共同完成扩容过程.。

/**
     * Rehashes the contents of this map into a new array with a
     * larger capacity.  This method is called automatically when the
     * number of keys in this map reaches its threshold.
     *
     * If current capacity is MAXIMUM_CAPACITY, this method does not
     * resize the map, but sets threshold to Integer.MAX_VALUE.
     * This has the effect of preventing future calls.
     *
     * @param newCapacity the new capacity, MUST be a power of two;
     *        must be greater than current capacity unless current
     *        capacity is MAXIMUM_CAPACITY (in which case value
     *        is irrelevant).
     */
    void resize(int newCapacity) {
        Entry[] oldTable = table;
        int oldCapacity = oldTable.length;
        if (oldCapacity == MAXIMUM_CAPACITY) {
            threshold = Integer.MAX_VALUE;
            return;
        }
		// 完成第一件事: 创建新的数组
        Entry[] newTable = new Entry[newCapacity];
        // 完成第二件事: 转移数组元素
        transfer(newTable);
        table = newTable;
        threshold = (int)(newCapacity * loadFactor);
    }

  /**
     * Transfers all entries from current table to newTable.
     */
    void transfer(Entry[] newTable) {
        Entry[] src = table;
        int newCapacity = newTable.length;
        for (int j = 0; j < src.length; j++) {
            Entry<K,V> e = src[j];
            if (e != null) {
                src[j] = null;
                do {
                    // 头插法完成数据的转移
                    Entry<K,V> next = e.next;
                    int i = indexFor(e.hash, newCapacity);
                    e.next = newTable[i];
                    newTable[i] = e;
                    e = next;
                } while (e != null);
            }
        }
    }

根据源码我们可以模拟一下场景。假设当前我们有一个内部存储有两个元素的容量capacity(即数组的长度)为2，负载因子为1的HashMap。（为了方便推测，我们将扩容条件设为与1.8相同，即元素个数大于threshold时才进行扩容，哈希索引方法设为哈希值对当前表长capacity取模）现在我们向其中放入一个新的元素，因为capacity*loadFactory = 2，当我们放入第三个元素之后扩容就会开始。

首先我们需要新建一个长度为原来2倍的数组

接下来就是transfer()方法的作用了，根据方法第7行的for循环我们可知这个方法会不辞劳苦的遍历原数组中的每一个元素并转移到新数组中。而我们的这个数组0索引位置为空，没进行有效操作，从1索引开始正式进入do…while循环进行头插法转移数据。

首先是第一轮循环：

• 先使用一个临时变量e存储当前遍历到的元素，next将当前遍历到的元素的下一个元素存储待用
• 接着根据元素的哈希值和新数组的大小计算出其在新数组中的索引位置（非常朴实的做法，到1.8中类似操作进行了极为精妙的处理，简直是艺术），这里我们直接用hash模上表长代替
• 头插法中的断链与续弦操作。将当前元素的下一个元素改为新表对应索引位置的元素，当前新表还没有数据，自然就是null，这也就保证头插法末尾元素的下一元素为空
• 将当前元素放入新表对应索引位置
• 将临时变量e指向下一元素（现在你就是我，下一元素成了当前元素。一次头插结束），判断循环是否继续
  

第二第三轮循环操作类似，直到最后当前元素为null结束循环，进入原数组下一索引进行同种操作，直至原数组中所有元素转移完毕

转移操作完成后新数组的引用将会被指定给原数组（注意每次fro循环判断当前元素不为null后都会将原数组对应索引位置置空），同时会计算出新的threshold。观察新的数组可以发现由于使用了头插法，原有的顺序其实已经被颠倒了过来，这也就为后续的一些问题埋下了祸根。

并发环状链表的形成

通过上边的叙述我们大致了解了HashMap扩容的整体过程，一切看起来虽然不怎么有美感，但还算是完美的实现了我们的目的对么？然而事情真的有这么简单么？

请设想这样一个场景。现在有两条线程争夺着时间片对同一个HashMap进行操作，我们姑且将这两条线程分别叫做线程一和线程二吧。

当线程一在扩容进行到根据hash值和数组长度取新索引步骤之前时时间片消耗完毕，线程二抢夺到资源开始进行扩容操作。

 Entry<K,V> next = e.next;
// 执行到上边这句话之后线程一时间片耗尽，此时现场中的e为Entry[3] next为Entry[7]
int i = indexFor(e.hash, newCapacity);

线程二比较幸运，执行完了整个transfer方法，但也止步于此，并未将新表的引用回传回去，这时线程一又抢夺到执行权继续进行刚才的扩容操作会发生什么有意思的事呢？

线程一在夺回执行权后执行现场保存的当前元素仍然是Entry[3] 它认为的当前元素的下一元素仍然是Entry[7]并以此继续执行循环。而实际上由于线程二的操作，Entry[7]与Entry[3]的位置关系已经调转。但是现在还暂时看不到影响，仍然是正常的将Entry[3]放入新数组的3索引位置。

仍然是看起来没什么异常的摘取Entry[7]采用头插法放入新数组3索引位置，将其下一元素指向Entry[3]

这时候问题就出现了，这轮循环重新把Entry[3]给摘了下来放到了原来Entry[7]所在的3索引位置（俗称你搁这你搁这呢？），同时将其下一元素指向Entry[7]而Entry[7]又无法通过别的方法进行断链将自己的next引用置为null，环就这样形成了。这时由于读到线程二改变过的Entry[3]的引用关系，当前元素e变为null循环结束，莫名其妙的多出来一个环而且丢失了Entry[5]元素。问题可不是一般的大。

环状链表的出现究其原因还是头插法的锅，因此在jdk1.8中resize()方法在数组拷贝的时候改用了尾插法，这个问题也就被修复了。

但是仍然不建议大家在并发的情况下使用HashMap，因为可以考虑一个很简单的问题，你怎么去保证并发下我取到的值就是原来的值而不是别的线程刚刚put进去的呢？何况HashMap这个东西本来就不是设计用来在并发情境下发挥作用的（难道说ConcurrentHashMap()她不够香么？）。这就是这篇水文的全部内容了，祝好，愿大家变得更强。