摘要
- 二進制計算的一些基礎知識
- 為什麼使用 hashcode
- String 類型的 hashcode 方法
- 為什麼大部分 hashcode 方法使用 31
- HashMap 的 hash 算法的實現原理（為什麼右移 16 位，為什麼要使用 ^ 位異或）
- HashMap 為什麼使用 & 與運算代替模運算？
- HashMap 的容量為什麼建議是 2的冪次方？
- 我們自定義 HashMap 容量最好是多少？
前言
作為一個有抱負的 Java 程序員，在經過長期的CRUD 和 HTML 填空之後必須有所思考，因為好奇心是驅動人類進步的動力之一，我們好奇，比如我們常用的 HashMap 到底是如何實現的？我想，說到這裡，稍微有點經驗的大佬都會說：擦，面試必問好嘛？怎麼可能不知道？
但是，我們真的瞭解他嗎？
我們知道 HashMap 依賴的 hashcode 和 hash 算法到底是怎麼實現的嘛？如果大佬說：早他麼知道了。那就裝不知道，聽樓主吹吹牛逼好不啦。。。。
今天樓主不會講 HashMap 的 put 方法實現和 get 方法實現，樓主要講的是 HashMap 高度依賴的 hashcode 和 hash 算法，雖然在很多書裡面，都說這是數學家應該去研究的事情，但我想，程序員也應該瞭解他是怎麼實現的。為什麼這麼做？就像娶老婆，你可能做不到創造老婆，但是你得知道你老婆是怎麼來的？家是哪的？為什麼喜歡你？扯遠了，回來，那麼今天我們就開始吧！
1. 二進制計算的一些基礎知識
首先，因為今天的文章會涉及到一些位運算，因此樓主怕大家忘了（其實樓主自己也忘了），因此貼出一些位運算符號的意思，以免看代碼的時候懵逼。
好了，大概瞭解一下就好了，因為位運算平時在項目裡真的用不上，在我們普通的業務項目裡，代碼易讀性比這點位運算性能要重要的多。但是，在框架中，位運算的必要性就顯示出來的了。因為需要服務大量的運算，性能要求也極高，如果性能渣渣，誰還用你？
2. 為什麼使用 hashcode
那麼我們就說說為什麼使用 hashcode ，hashCode 存在的第一重要的原因就是在 HashMap(HashSet 其實就是HashMap) 中使用（其實Object 類的 hashCode 方法註釋已經說明了 ），我知道，HashMap 之所以速度快，因為他使用的是散列表，根據 key 的 hashcode 值生成數組下標（通過內存地址直接查找，沒有任何判斷），時間複雜度完美情況下可以達到 n1（和數組相同，但是比數組用著爽多了，但是需要多出很多內存，相當於以空間換時間）。
3. String 類型的 hashcode 方法
在 JDK 中，Object 的 hashcode 方法是本地方法，也就是用 c 語言或 c++ 實現的，該方法直接返回對象的 內存地址。這麼做會有說明問題呢？我們用代碼看看：
這段代碼打印出來的會是什麼呢？ 答： null。因為我們沒有重寫 hashCode 方法，所有，HashMap 內部使用的是該對象的內存地址，那麼肯定不一樣。我們第一個對象根本就沒有存，因此，返回就是 null。這裡就可以看出來重寫 hashCode 的重要性。
JDK 中，我們經常把 String 類型作為 key，那麼 String 類型是如何重寫 hashCode 方法的呢？
我們看看代碼：
代碼非常簡單，就是使用 String 的 char 數組的數字每次乘以 31 再疊加最後返回，因此，每個不同的字符串，返回的 hashCode 肯定不一樣。那麼為什麼使用 31 呢？
4. 為什麼大部分 hashcode 方法使用 31
如果有使用 eclipse 的同學肯定知道，該工具默認生成的 hashCode 方法實現也和 String 類型差不多。都是使用的 31 ，那麼有沒有想過：為什麼要使用 31 呢？
在名著 《Effective Java》第 42 頁就有對 hashCode 為什麼採用 31 做了說明：
之所以使用 31， 是因為他是一個奇素數。如果乘數是偶數，並且乘法溢出的話，信息就會丟失，因為與2相乘等價於移位運算（低位補0）。使用素數的好處並不很明顯，但是習慣上使用素數來計算散列結果。 31 有個很好的性能，即用移位和減法來代替乘法，可以得到更好的性能： 31 * i == (i << 5） - i， 現代的 VM 可以自動完成這種優化。這個公式可以很簡單的推導出來。這個問題在 SO 上也有討論： https://stackoverflow.com/questions/299304/why-does-javas-hashcode-in-string-use-31-as-a-multiplier%EF%BC%89
可以看到，使用 31 最主要的還是為了性能。當然用 63 也可以。但是 63 的溢出風險就更大了。那麼15 呢？仔細想想也可以。
在《Effective Java》也說道：編寫這種散列函數是個研究課題，最好留給數學家和理論方面的計算機科學家來完成。我們此次最重要的是知道了為什麼使用31。
5. HashMap 的 hash 算法的實現原理（為什麼右移 16 位，為什麼要使用 ^ 位異或）
好了，知道了 hashCode 的生成原理了，我們要看看今天的主角，hash 算法。
其實，這個也是數學的範疇，從我們的角度來講，只要知道這是為了更好的均勻散列表的下標就好了，但是，就是耐不住好奇心啊！ 能多知道一點就是一點，我們來看看 HashMap 的 hash 算法（JDK 8）.
乍看一下就是簡單的異或運算和右移運算，但是為什麼要異或呢？為什麼要移位呢？而且移位16？
在分析這個問題之前，我們需要先看看另一個事情，什麼呢？就是 HashMap 如何根據 hash 值找到數組種的對象，我們看看 get 方法的代碼：
我們看看代碼中註釋下方的一行代碼：first = tab[(n - 1) & hash])。
使用數組長度減一 與運算 hash 值。這行代碼就是為什麼要讓前面的 hash 方法移位並異或。
我們分析一下：
首先，假設有一種情況，對象 A 的 hashCode 為 1000010001110001000001111000000，對象 B 的 hashCode 為 0111011100111000101000010100000。
如果數組長度是16，也就是 15 與運算這兩個數， 你會發現結果都是0。這樣的散列結果太讓人失望了。很明顯不是一個好的散列算法。
但是如果我們將 hashCode 值右移 16 位，也就是取 int 類型的一半，剛好將該二進制數對半切開。並且使用位異或運算（如果兩個數對應的位置相反，則結果為1，反之為0），這樣的話，就能避免我們上面的情況的發生。
總的來說，使用位移 16 位和 異或 就是防止這種極端情況。但是，該方法在一些極端情況下還是有問題，比如：10000000000000000000000000 和 1000000000100000000000000 這兩個數，如果數組長度是16，那麼即使右移16位，在異或，hash 值還是會重複。但是為了性能，對這種極端情況，JDK 的作者選擇了性能。畢竟這是少數情況，為了這種情況去增加 hash 時間，性價比不高。
6. HashMap 為什麼使用 & 與運算代替模運算？
好了，知道了 hash 算法的實現原理還有他的一些取捨，我們再看看剛剛說的那個根據hash計算下標的方法：
tab[(n - 1) & hash]；
其中 n 是數組的長度。其實該算法的結果和模運算的結果是相同的。但是，對於現代的處理器來說，除法和求餘數（模運算）是最慢的動作。
上面情況下和模運算相同呢？
a % b == (b-1) & a ,當b是2的指數時，等式成立。
我們說 & 與運算的定義：與運算 第一個操作數的的第n位於第二個操作數的第n位如果都是1，那麼結果的第n為也為1，否則為0；
當 n 為 16 時， 與運算 101010100101001001101 時，也就是
1111 & 101010100101001001000 結果：1000 = 8
1111 & 101000101101001001001 結果：1001 = 9
1111 & 101010101101101001010 結果： 1010 = 10
1111 & 101100100111001101100 結果： 1100 = 12
可以看到，當 n 為 2 的冪次方的時候，減一之後就會得到 1111* 的數字，這個數字正好可以掩碼。並且得到的結果取決於 hash 值。因為 hash 值是1，那麼最終的結果也是1 ，hash 值是0，最終的結果也是0。
7. HashMap 的容量為什麼建議是 2的冪次方？
到這裡，我們提了一個關鍵的問題： HashMap 的容量為什麼建議是 2的冪次方？正好可以和上面的話題接上。樓主就是這麼設計的。
為什麼要 2 的冪次方呢？
我們說，hash 算法的目的是為了讓hash值均勻的分佈在桶中（數組），那麼，如何做到呢？試想一下，如果不使用 2 的冪次方作為數組的長度會怎麼樣？
假設我們的數組長度是10，還是上面的公式：
1010 & 101010100101001001000 結果：1000 = 8
1010 & 101000101101001001001 結果：1000 = 8
1010 & 101010101101101001010 結果： 1010 = 10
1010 & 101100100111001101100 結果： 1000 = 8
看到結果我們驚呆了，這種散列結果，會導致這些不同的key值全部進入到相同的插槽中，形成鏈表，性能急劇下降。
所以說，我們一定要保證 & 中的二進制位全為 1，才能最大限度的利用 hash 值，並更好的散列，只有全是1 ，才能有更多的散列結果。如果是 1010，有的散列結果是永遠都不會出現的，比如 0111，0101，1111，1110…….，只要 & 之前的數有 0， 對應的 1 肯定就不會出現（因為只有都是1才會為1）。大大限制了散列的範圍。
8. 我們自定義 HashMap 容量最好是多少？
那我們如何自定義呢？自從有了阿里的規約插件，每次樓主都要初始化容量，如果我們預計我們的散列表中有2個數據，那麼我就初始化容量為2嘛？
絕對不行，如果大家看過源碼就會發現，如果Map中已有數據的容量達到了初始容量的 75%，那麼散列表就會擴容，而擴容將會重新將所有的數據重新散列，性能損失嚴重，所以，我們可以必須要大於我們預計數據量的 1.34 倍，如果是2個數據的話，就需要初始化 2.68 個容量。當然這是開玩笑的，2.68 不可以，3 可不可以呢？肯定也是不可以的，我前面說了，如果不是2的冪次方，散列結果將會大大下降。導致出現大量鏈表。那麼我可以將初始化容量設置為4。 當然了，如果你預計大概會插入 12 條數據的話，那麼初始容量為16簡直是完美，一點不浪費，而且也不會擴容。
總結
好了，分析完了 hashCode 和 hash 算法，讓我們對 HashMap 又有了全新的認識。當然，HashMap 中還有很多有趣的東西值得挖掘，樓主會繼續寫下去。爭取將 HashMap 的衣服扒光。
總的來說，通過今天的分析，對我們今後使用 HashMap 有了更多的把握，也能夠排查一些問題，比如鏈表數很多，肯定是數組初始化長度不對，如果某個map很大，注意，肯定是事先沒有定義好初始化長度，假設，某個Map存儲了10000個數據，那麼他會擴容到 20000，實際上，根本不用 20000，只需要 10000* 1.34= 13400 個，然後向上找到一個2 的冪次方，也就是 16384 初始容量足夠。
good luck ！！！！
閱讀更多 實用架構技術 的文章
