之前看到一篇帖子討論初始化HashMap的時候是否應該設置初始容量，那篇帖子講了很多，最後的結論是應該設置，但是設置成多少沒有提，評論區有不少人說那就用多少設置多少，比如用6個就設置爲6。
且不說真正業務場景上你是很難提前定義一個集合類應該存放多少數據的，因爲大多數場景都是業務相關決定的，就算真的可能確定，也不應該是這樣一個結論，因爲你設置的值其實並不是HashMap初始化時真正的容量，真正的初始化容量是大於你設置的容量的第一個2次冪。
爲什麼這麼設計呢，其實是和HashMap的底層涉及有關，我們知道HashMap是一個數組➕鏈表（之後是紅黑樹）的結構，根據當前key的Hash值來確定數組中的位置，如果這個位置選擇的不好，就會導致數組有一些地方始終放不進去值，有一些地方一直在鏈式加元素，造成資源的浪費。
這個HashMap中的位置是怎麼計算的，我們再看看代碼
核心就是這一句
p = tab[i = (n - 1) & hash]
這裏關注下(n - 1) & hash，n是目前的數組容量，hash是當前key的hash值，看到n-1你可能已經有感覺了，我們不妨把n的各種情況模擬一下，假設n=16，hash值從0遞增
| hash值 | (n - 1) & hash | 結果 |
| 0 | 1111&0000 | 0 |
| 1 | 1111&0001 | 1 |
| 2 | 1111&0010 | 2 |
| 3 | 1111&0011 | 3 |
| 4 | 1111&0100 | 4 |
| ... | ... | ... |
| 14 | 1111&1110 | 14 |
| 15 | 1111&1111 | 15 |
| 16 | 01111&10000 | 0（鏈式存儲在0後面） |
能發現算出來的位置基本是散列開的，很均勻。
那麼我們把n換成15試試，n-1 = 14 (1110)
| hash值 | (n - 1) & hash | 結果 |
| 0 | 1110&0000 | 0 |
| 1 | 1110&0001 | 0 |
| 2 | 1110&0010 | 2 |
| 3 | 1110&0011 | 2 |
| 4 | 1110&0100 | 4 |
| ... | ... | ... |
| 14 | 1110&1110 | 14 |
| 15 | 1110&1111 | 14 |
會發現0，2，4等位置都鏈式存儲了兩個數據，而1，3等位置始終沒有數據存儲，這就造成了浪費。
這裏面還有一個小彩蛋，其實這種計算數組位置的問題，我的第一想法就是取餘運算，那麼爲什麼這裏不用取餘呢？取餘就沒這個問題了，這裏其實還是因爲&的性能要優於取餘運算，實際上位運算(&)效率要比代替取模運算(%)高很多，主要原因是位運算直接對內存數據進行操作，不需要轉成十進制，因此處理速度非常快。所以這種最底層的計算邏輯，優先考慮位運算，這樣就不難理解爲什麼如此設計了