HashMap你瞭解多少

HashMap幾乎是面試必問的知識，對於HashMap面試是你真的能從容面對嗎？相信若是你去面試知名互聯網公司的時候，決對不會只是問問你HashMap的數據結構這麼簡單的問題。我收集了最近老大在面試過程當中關於HashMap常問的幾個問題：

1. 爲何HashMap是2的冪次方？

new HashMap(14);

HashMap是由數組+鏈表（1.8還有紅黑樹）來實現的，那麼上面這行代碼它執行後，建立的數組大小是多少呢？
追蹤源碼能夠看到它會執行這樣一個函數來返回數組大小的：

static final int tableSizeFor(int cap) {
    int n = cap - 1;
    n |= n >>> 1;
    n |= n >>> 2;
    n |= n >>> 4;
    n |= n >>> 8;
    n |= n >>> 16;
    return (n < 0) ? 1 : (n >= MAXIMUM_CAPACITY) ? MAXIMUM_CAPACITY : n + 1;
}

圖解：

• 第一次右移而且或運算，能夠保證從左到右第一位1後面再多出來一個1
• 第二次右移而且或運算，能夠保證從左到右再多出兩個1
• 以此類推，由於java中int值是4個字節，32位的，因此最後移16位的時候，足以保證2^32這種狀況的出現；

• 經過這個函數的運算，能夠將咱們傳入的14運算獲得16，也就是大於14的最小的2的n次冪。

上面說明了數組大小最後會保證是2的n次冪，那麼接下來講說爲何要保證是2的n次冪

static int indexFor(int h, int length) {
     return h & (length-1);
 }

在jdk1.7的時候，在put元素時，會執行這樣一段代碼片斷，它的用意就是數據長度與hashCode值取餘運算。那既然是取餘，爲何不直接用%號呢？是由於位運算要比%運算高效不少。

那既然是&運算，又爲何非要保證length是2^n呢？

• 長度是2^n-1的話，能夠保證&的結果是在hash表的大小範圍內；
• &運算與%取模的結果能夠保證一致；

2. 爲何HashMap的擴容因子是0.75？

加載因子是很是重要的一塊，若是加載因子太大，假如爲1，那麼從空間利用率卻是上去了，可是時間效率就下降了。
若是加載因子過小，倒致使hashmap頻繁的擴容操做，每次擴容都很是耗性能；
好吧！說了就像沒說同樣，關於這個問題我也只能拋磚引玉；
實際上是這樣的：

Because TreeNodes are about twice the size of regular nodes, we
 * use them only when bins contain enough nodes to warrant use
 * (see TREEIFY_THRESHOLD). And when they become too small (due to
 * removal or resizing) they are converted back to plain bins.  In
 * usages with well-distributed user hashCodes, tree bins are
 * rarely used.  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
 * more: less than 1 in ten million

選擇0.75是空間和時間的一個折中，也並非說，非必須是0.75，其它的編程語言也有配置成0.72的。

3. jdk1.7擴容時是怎麼產生死循環的？

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

提及這個話題，當時在網上找博客看是真沒有能看懂的，因此我儘可能用圖的方式來表述

4. jdk1.8擴容時會產生死循環嗎？

Node<K,V> loHead = null, loTail = null;
Node<K,V> hiHead = null, hiTail = null;
Node<K,V> next;
do {
        next = e.next;
        if ((e.hash & oldCap) == 0) {
                if (loTail == null)
                        loHead = e;
                else
                        loTail.next = e;
                loTail = e;
        }
        else {
                if (hiTail == null)
                        hiHead = e;
                else
                        hiTail.next = e;
                hiTail = e;
        }
} while ((e = next) != null);
if (loTail != null) {
        loTail.next = null;
        newTab[j] = loHead;
}
if (hiTail != null) {
        hiTail.next = null;
        newTab[j + oldCap] = hiHead;
}

看下方圖文分析：

因此，jdk1.8中的HashMap在擴容時就不會產生死鎖了！

5. 爲何是鏈表長度達到8時轉爲紅黑樹？

首先，TreeNode節點的佔用空間的大小是鏈表節點的兩倍，只有當容器達到8的時候才轉爲紅黑樹，爲何是8呢，在第二個問題中已經說明了，根據泊松分佈能夠看出，鏈表節點是很難達到長度爲8的時候的，若是真有特殊狀況達到8了，那麼纔將鏈表轉爲紅黑樹；
轉爲紅黑樹時還有個要求，就是hashMap中的元素個數達到64。

6. jdk1.8 HashMap是線程安全的嗎？

JDK1.8HashMap雖然可以盡大的避免擴容時死循環問題，可是，HashMap仍然是線程不安全的，例如：線程A在put元素時，線程B進行擴容；之因此不安全的緣由是多線程會操做同一實例變化，致使變量狀態不一致；