hashmap的擴容機制

      一、當咱們往hashmap中put元素的時候，先根據key的hash值獲得這個元素在 數組中的位置（即下標），而後就能夠把這個元素放到對應的位置中了。若是這個元素所在的位子上已經存放有其餘元素了，那麼在同一個位子上的元素將以鏈表的 形式存放，新加入的放在鏈頭，好比a->b->c，新加入的d放到a的位置前面，最早加入的放在鏈尾，也就是c。最後變成d->a->b->c，從hashmap中get元素時，首先計算key的hashcode，找到數組中對應位置的某一元素， 而後經過key的equals方法在對應位置的鏈表中找到須要的元素。

 

 二、

在hashmap中要找到 某個元素，須要根據key的hash值來求得對應數組中的位置。如何計算這個位置就是hash算法。前面說過hashmap的數據結構是數組和鏈表的結 合，因此咱們固然但願這個hashmap裏面的元素位置儘可能的分佈均勻些，儘可能使得每一個位置上的元素數量只有一個，那麼當咱們用hash算法求得這個位置 的時候，立刻就能夠知道對應位置的元素就是咱們要的，而不用再去遍歷鏈表。

因此咱們首先想到的就是把hashcode對數組長度取模運算，這樣一來，元素的分佈相對來講是比較均勻的。可是，「模」運算的消耗仍是比較大的，能不能找一種更快速，消耗更小的方式那？java中時這樣作的，

 

Java代碼

 

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

首 先算得key得hashcode值，而後跟數組的長度-1作一次「與」運算（&）。看上去很簡單，其實比較有玄機。好比數組的長度是2的4次方， 那麼hashcode就會和2的4次方-1作「與」運算。不少人都有這個疑問，爲何hashmap的數組初始化大小都是2的次方大小時，hashmap 的效率最高，我以2的4次方舉例，來解釋一下爲何數組大小爲2的冪時hashmap訪問的性能最高。

         看下圖，左邊兩組是數組長度爲16（2的4次方），右邊兩組是數組長度爲15。兩組的hashcode均爲8和9，可是很明顯，當它們和1110「與」的 時候，產生了相同的結果，也就是說它們會定位到數組中的同一個位置上去，這就產生了碰撞，8和9會被放到同一個鏈表上，那麼查詢的時候就須要遍歷這個鏈 表，獲得8或者9，這樣就下降了查詢的效率。同時，咱們也能夠發現，當數組長度爲15的時候，hashcode的值會與14（1110）進行「與」，那麼 最後一位永遠是0，而0001，0011，0101，1001，1011，0111，1101這幾個位置永遠都不能存放元素了，空間浪費至關大，更糟的是 這種狀況中，數組可使用的位置比數組長度小了不少，這意味着進一步增長了碰撞的概率，減慢了查詢的效率！ 

 


          因此說，當數組長度爲2的n次冪的時候，不一樣的key算得得index相同的概率較小，那麼數據在數組上分佈就比較均勻，也就是說碰撞的概率小，相對的，查詢的時候就不用遍歷某個位置上的鏈表，這樣查詢效率也就較高了。
          說到這裏，咱們再回頭看一下hashmap中默認的數組大小是多少，查看源代碼能夠得知是16，爲何是16，而不是15，也不是20呢，看到上面 annegu的解釋以後咱們就清楚了吧，顯然是由於16是2的整數次冪的緣由，在小數據量的狀況下16比15和20更能減小key之間的碰撞，而加快查詢 的效率。

三、

      當hashmap中的元素愈來愈多的時候，碰撞的概率也就愈來愈高（由於數組的長度是固定的），因此爲了提升查詢的效率，就要對hashmap的數組進行 擴容，數組擴容這個操做也會出如今ArrayList中，因此這是一個通用的操做，不少人對它的性能表示過懷疑，不過想一想咱們的「均攤」原理，就釋然了， 而在hashmap數組擴容以後，最消耗性能的點就出現了：原數組中的數據必須從新計算其在新數組中的位置，並放進去，這就是resize。

         那麼hashmap何時進行擴容呢？當hashmap中的元素個數超過數組大小*loadFactor時，就會進行數組擴容，loadFactor的 默認值爲0.75，也就是說，默認狀況下，數組大小爲16，那麼當hashmap中元素個數超過16*0.75=12的時候，就把數組的大小擴展爲 2*16=32，即擴大一倍，而後從新計算每一個元素在數組中的位置，而這是一個很是消耗性能的操做，因此若是咱們已經預知hashmap中元素的個數，那 麼預設元素的個數可以有效的提升hashmap的性能。好比說，咱們有1000個元素new HashMap(1000), 可是理論上來說new HashMap(1024)更合適，不過上面annegu已經說過，即便是1000，hashmap也自動會將其設置爲1024。 可是new HashMap(1024)還不是更合適的，由於0.75*1000 < 1000, 也就是說爲了讓0.75 * size > 1000, 咱們必須這樣new HashMap(2048)才最合適，既考慮了&的問題，也避免了resize的問題。