集合是Java開發日常開發中經常會使用到的，而作為一種典型的K-V結構的資料結構，HashMap對於Java開發者一定不陌生。
關於HashMap，很多人都對他有一些基本的瞭解，比如他和hashtable之間的區別、他和concurrentHashMap之間的區別等。這些都是比較常見的，關於HashMap的一些知識點和麵試題，想來大家一定了熟於心了，並且在開發中也能有效的應用上。
但是，作者在很多次 CodeReview 以及面試中發現，有一個比較關鍵的小細節經常被忽視，那就是HashMap建立的時候，要不要指定容量？如果要指定的話，多少是合適的？為什麼？
要設定HashMap的初始化容量
在《HashMap中傻傻分不清楚的那些概念》中我們曾經有過以下結論：
HashMap有擴容機制，就是當達到擴容條件時會進行擴容。HashMap的擴容條件就是當HashMap中的元素個數（size）超過臨界值（threshold）時就會自動擴容。在HashMap中，threshold = loadFactor * capacity。
所以，如果我們沒有設定初始容量大小，隨著元素的不斷增加，HashMap會發生多次擴容，而HashMap中的擴容機制決定了每次擴容都需要重建hash表，是非常影響效能的。
所以，首先可以明確的是，我們建議開發者在建立HashMap的時候指定初始化容量。並且《阿里巴巴開發手冊》中也是這麼建議的：
HashMap初始化容量設定多少合適
那麼，既然建議我們集合初始化的時候，要指定初始值大小，那麼我們建立HashMap的時候，到底指定多少合適呢？
有些人會自然想到，我準備塞多少個元素我就設定成多少唄。比如我準備塞7個元素，那就new HashMap(7)。
但是，這麼做不僅不對，而且以上方式建立出來的Map的容量也不是7。
因為，當我們使用HashMap(int initialCapacity)來初始化容量的時候，HashMap並不會使用我們傳進來的initialCapacity直接作為初識容量。
JDK會預設幫我們計算一個相對合理的值當做初始容量。所謂合理值，其實是找到第一個比使用者傳入的值大的2的冪。
也就是說，當我們new HashMap(7)建立HashMap的時候，JDK會通過計算，幫我們建立一個容量為8的Map；當我們new HashMap(9)建立HashMap的時候，JDK會通過計算，幫我們建立一個容量為16的Map。
但是，這個值看似合理，實際上並不盡然。因為HashMap在根據使用者傳入的capacity計算得到的預設容量，並沒有考慮到loadFactor這個因素，只是簡單機械的計算出第一個大約這個數字的2的冪。
loadFactor是負載因子，當HashMap中的元素個數（size）超過 threshold = loadFactor * capacity時，就會進行擴容。
也就是說，如果我們設定的預設值是7，經過JDK處理之後，HashMap的容量會被設定成8，但是，這個HashMap在元素個數達到 8*0.75 = 6的時候就會進行一次擴容，這明顯是我們不希望見到的。
那麼，到底設定成什麼值比較合理呢？
這裡我們可以參考JDK8中putAll方法中的實現的，這個實現在guava（21.0版本）也被採用。
這個值的計算方法就是：
return (int) ((float) expectedSize / 0.75F + 1.0F);
複製程式碼比如我們計劃向HashMap中放入7個元素的時候，我們通過expectedSize / 0.75F + 1.0F計算，7/0.75 + 1 = 10 ,10經過JDK處理之後，會被設定成16，這就大大的減少了擴容的機率。
當HashMap內部維護的雜湊表的容量達到75%時（預設情況下），會觸發rehash，而rehash的過程是比較耗費時間的。所以初始化容量要設定成expectedSize/0.75 + 1的話，可以有效的減少衝突也可以減小誤差。（大家結合這個公式，好好理解下這句話）
所以，我們可以認為，當我們明確知道HashMap中元素的個數的時候，把預設容量設定成expectedSize / 0.75F + 1.0F 是一個在效能上相對好的選擇，但是，同時也會犧牲些記憶體。
這個演算法在guava中有實現，開發的時候，可以直接通過Maps類建立一個HashMap：
Map<String, String> map = Maps.newHashMapWithExpectedSize(7);
複製程式碼其程式碼實現如下：
public static <K, V> HashMap<K, V> newHashMapWithExpectedSize(int expectedSize) {
return new HashMap(capacity(expectedSize));
}
static int capacity(int expectedSize) {
if (expectedSize < 3) {
CollectPreconditions.checkNonnegative(expectedSize, "expectedSize");
return expectedSize + 1;
} else {
return expectedSize < 1073741824 ? (int)((float)expectedSize / 0.75F + 1.0F) : 2147483647;
}
}
複製程式碼但是，以上的操作是一種用記憶體換效能的做法，真正使用的時候，要考慮到記憶體的影響。 但是，大多數情況下，我們還是認為記憶體是一種比較富裕的資源。
但是話又說回來了，有些時候，我們到底要不要設定HashMap的初識值，這個值又設定成多少，真的有那麼大影響嗎？其實也不見得！
可是，大的效能優化，不就是一個一個的優化細節堆疊出來的嗎？
再不濟，以後你寫程式碼的時候，使用Maps.newHashMapWithExpectedSize(7);的寫法，也可以讓同事和老闆眼前一亮。
或者哪一天你碰到一個面試官問你一些細節的時候，你也能有個印象，或者某一天你也可以拿這個出去面試問其他人~！啊哈哈哈。
