我們知道在hashmap中要找到某個元素，需要根據(jù)key的hash值來求得對應(yīng)數(shù)組中的位置。如何計算這個位置就是hash算法。前面說過hashmap的數(shù)據(jù)結(jié)構(gòu)是數(shù)組和鏈表的結(jié)合，所以我們當(dāng)然希望這個hashmap里面的元素位置盡量的分布均勻些，盡量使得每個位置上的元素數(shù)量只有一個，那么當(dāng)我們用hash算法求得這個位置的時候，馬上就可以知道對應(yīng)位置的元素就是我們要的，而不用再去遍歷鏈表
所以我們首先想到的就是把hashcode對數(shù)組長度取模運算，這樣一來，元素的分布相對來說是比較均勻的。但是，“模”運算的消耗還是比較大的，能不能找一種更快速，消耗更小的方式那？java中時這樣做的，

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

首先算得key得hashcode值，然后跟數(shù)組的長度-1做一次“與”運算（&）。看上去很簡單，其實比較有玄機(jī)。比如數(shù)組的長度是2的4次方，那么hashcode就會和2的4次方-1做“與”運算。很多人都有這個疑問，為什么hashmap的數(shù)組初始化大小都是2的次方大小時，hashmap的效率最高，我以2的4次方舉例，來解釋一下為什么數(shù)組大小為2的冪時hashmap訪問的性能最高。
看下圖，左邊兩組是數(shù)組長度為16（2的4次方），右邊兩組是數(shù)組長度為15。兩組的hashcode均為8和9，但是很明顯，當(dāng)它們和1110“與”的時候，產(chǎn)生了相同的結(jié)果，也就是說它們會定位到數(shù)組中的同一個位置上去，這就產(chǎn)生了碰撞，8和9會被放到同一個鏈表上，那么查詢的時候就需要遍歷這個鏈表，得到8或者9，這樣就降低了查詢的效率。同時，我們也可以發(fā)現(xiàn)，當(dāng)數(shù)組長度為15的時候，hashcode的值會與14（1110）進(jìn)行“與”，那么最后一位永遠(yuǎn)是0，而0001，0011，0101，1001，1011，0111，1101這幾個位置永遠(yuǎn)都不能存放元素了，空間浪費相當(dāng)大，更糟的是這種情況中，數(shù)組可以使用的位置比數(shù)組長度小了很多，這意味著進(jìn)一步增加了碰撞的幾率，減慢了查詢的效率！

所以說，當(dāng)數(shù)組長度為2的n次冪的時候，不同的key算得得index相同的幾率較小，那么數(shù)據(jù)在數(shù)組上分布就比較均勻，也就是說碰撞的幾率小，相對的，查詢的時候就不用遍歷某個位置上的鏈表，這樣查詢效率也就較高了。
說到這里，我們再回頭看一下hashmap中默認(rèn)的數(shù)組大小是多少，查看源代碼可以得知是16，為什么是16，而不是15，也不是20呢，看到上面annegu的解釋之后我們就清楚了吧，顯然是因為16是2的整數(shù)次冪的原因，在小數(shù)據(jù)量的情況下16比15和20更能減少key之間的碰撞，而加快查詢的效率。

所以，在存儲大容量數(shù)據(jù)的時候，最好預(yù)先指定hashmap的size為2的整數(shù)次冪次方。就算不指定的話，也會以大于且最接近指定值大小的2次冪來初始化的，代碼如下(HashMap的構(gòu)造方法中)：

// Find a power of 2 >= initialCapacity int capacity = 1; while (capacity < initialCapacity) capacity <<= 1;

總結(jié)：
本文主要描述了HashMap的結(jié)構(gòu)，和hashmap中hash函數(shù)的實現(xiàn)，以及該實現(xiàn)的特性，同時描述了hashmap中resize帶來性能消耗的根本原因，以及將普通的域模型對象作為key的基本要求。尤其是hash函數(shù)的實現(xiàn)，可以說是整個HashMap的精髓所在，只有真正理解了這個hash函數(shù)，才可以說對HashMap有了一定的理解。

總結(jié)

以上是生活随笔為你收集整理的hashmap为什么容量是2的n次方的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。