深入理解 hashcode() 和 HashMap 中的hash 演算法
前言
Java中的HashMap非常常用也非常重要, 提到HashMap是離不開hashcode()方法的, 整天嘴邊掛著HashMap、Hashtable、TreeMap、LinkedHashMap、IdentityHashMap、ConcurrentHashMap和WeakHashMap等詞, 也許用起來簡單, hash的原理也很簡單, 經常不以為然, 但是細想下來總覺得有哪裡有疑惑, 這裡細緻分析一下hashcode與hashmap中用到的hash演算法
hash是什麼
hash是一個函式，該函式中的實現就是一種演算法，就是通過一系列的演算法來得到一個hash值，這個時候，我們就需要知道另一個東西，hash表，通過hash演算法得到的hash值就在這張hash表中，也就是說，hash表就是所有的hash值組成的，有很多種hash函式，也就代表著有很多種演算法得到hash值, 編寫雜湊函式是老生常談的研究課題，是數學家和理論方面的電腦科學家的研究任務, 我們只需要知道那些比較好用, 大概為啥好用就可以了
hashcode是啥
hashcode就是通過hash函式得來的，通俗的說，就是通過某一種演算法得到的，hashcode就是在hash表中有對應的位置。
每個物件都有hashcode，物件的hashcode怎麼得來的呢？
首先一個物件肯定有實體地址，網上有人把物件的hashcode說成是物件的地址，事實上這種看法是不全面的，確實有些JVM在實現時是直接返回物件的儲存地址，但是大多時候並不是這樣，只能說可能儲存地址有一定關聯, 那麼物件如何得到hashcode呢？通過物件的內部地址(也就是實體地址)轉換成一個整數，然後該整數通過hash函式的演算法就得到了hashcode(不同jvm的實現不同)
為什麼使用 HashCode
HashCode的存在主要是為了查詢的快捷性, HashCode是用來在雜湊儲存結構中確定物件的儲存地址的 ( 後半句說的用hashcode來代表物件在hash表中的位置 ) , hashCode 存在的最重要的原因就是在 HashMap(HashSet 其實就是HashMap) 中使用（其實Object 類的 hashCode 方法註釋已經說明了 ），HashMap 之所以速度快，因為他使用的是散列表，根據 key 的 hashcode 值生成陣列下標
比如：我們有一個能存放1000個數這樣大的記憶體中，在其中要存放1000個不一樣的數字，用最笨的方法，就是存一個數字，就遍歷一遍，看有沒有相同得數，當存了900個數字，開始存901個數字的時候，就需要跟900個數字進行對比，這樣就很麻煩，很是消耗時間，用hashcode來記錄物件的位置，來看一下。hash表中有1、2、3、4、5、6、7、8個位置，存第一個數，hashcode為1，該數就放在hash表中1的位置，存到100個數字，hash表中8個位置會有很多數字了，1中可能有20個數字，存101個數字時，他先查hashcode值對應的位置，假設為1，那麼就有20個數字和他的hashcode相同，他只需要跟這20個數字相比較(equals)，如果每一個相同，那麼就放在1這個位置，這樣比較的次數就少了很多，實際上hash表中有很多位置，這裡只是舉例只有8個，所以比較的次數會讓你覺得也挺多的，實際上，如果hash表很大，那麼比較的次數就很少很少了。 通過對原始方法和使用hashcode方法進行對比，我們就知道了hashcode的作用，並且為什麼要使用hashcode了
equals方法和hashcode的關係？
關於這點又是一大篇, 直接上結論, 想細緻瞭解的看我轉的一位大佬的部落格:
https://blog.csdn.net/q5706503/article/details/84076261
歸納總結：
1.若重寫了equals(Object obj)方法，則有必要重寫hashCode()方法。
2.若兩個物件equals(Object obj)返回true，則hashCode（）有必要也返回相同的int數。
3.若兩個物件equals(Object obj)返回false，則hashCode（）不一定返回不同的int數。
4.若兩個物件hashCode（）返回相同int數，則equals（Object obj）不一定返回true。
5.若兩個物件hashCode（）返回不同int數，則equals（Object obj）一定返回false。
6.同一物件在執行期間若已經儲存在集合中，則不能修改影響hashCode值的相關資訊，否則會導致記憶體洩露問題。
String 型別的 hashcode 方法
我們看一個例子:
class Test1{
String name;
public Test1(String name) {
this.name = name;
}
public static void main(String[] args) {
Map<Test1, String> map = new HashMap<>(4);
map.put(new Test1("hello"), "hello");
String hello = map.get(new Test1("hello"));
System.out.println(hello);
}
}這段程式碼打印出來的會是什麼呢？
答： null。
從某個角度說，這兩個物件是一樣的，因為名稱一樣，name 屬性都是 hello，當我們使用這個 key 時，按照邏輯，應該返回 hello 給我們。但是，由於沒有重寫 hashcode 方法，JDK 預設使用 Objective 類的 hashcode 方法，返回的是一個虛擬記憶體地址，而每個物件的虛擬地址都是不同的，所以，這個肯定不會返回 hello 。
如果我們重寫 hashcode 和 equals 方法：
@Override
public boolean equals(Object o) {
if (this == o) {
return true;
}
if (o == null || getClass() != o.getClass()) {
return false;
}
Test1 test1 = (Test1) o;
return Objects.equals(name, test1.name);
}
@Override
public int hashCode() {
return Objects.hash(name);
}再次執行：得到的結果就不是 null 了，而是 hello。
這才是比較符合邏輯，符合直覺的。
JDK 中，我們經常把 String 型別作為 key，那麼 String 型別是如何重寫 hashCode 方法的呢？
我們看看程式碼：
public int hashCode() {
int h = hash;
if (h == 0 && value.length > 0) {
char val[] = value;
for (int i = 0; i < value.length; i++) {
h = 31 * h + val[i];
}
hash = h;
}
return h;
}程式碼非常簡單，就是使用 String 的 char 陣列的數字每次乘以 31 再疊加最後返回，因此，每個不同的字串，返回的 hashCode 肯定不一樣。那麼為什麼使用 31 呢？
為什麼大部分 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）
可以看到，使用 31 最主要的還是為了效能。當然用 63 也可以。但是 63 的溢位風險就更大了。那麼15 呢？仔細想想也可以。
在《Effective Java》也說道：編寫這種雜湊函式是個研究課題，最好留給數學家和理論方面的電腦科學家來完成。我們此次最重要的是知道了為什麼使用31。
HashMap 的 hash 演算法的實現原理（為什麼右移 16 位，為什麼要使用 ^ 位異或）
好了，知道了 hashCode 的生成原理了，我們要看看今天的主角，hash 演算法。
其實，這個也是數學的範疇，從我們的角度來講，只要知道這是為了更好的均勻散列表的下標就好了，我們來看看 HashMap 的 hash 演算法（JDK 8）.
static final int hash(Object key) {
int h;
return (key == null) ? 0 : (h = key.hashCode()) ^ (h >>> 16);
}乍看一下就是簡單的異或運算和右移運算，但是為什麼要異或呢？為什麼要移位呢？而且移位16？
在分析這個問題之前，我們需要先看看另一個事情， HashMap 如何根據 hash 值找到陣列中的物件，我們看看 get 方法的程式碼：
final Node<K,V> getNode(int hash, Object key) {
Node<K,V>[] tab; Node<K,V> first, e; int n; K k;
if ((tab = table) != null && (n = tab.length) > 0 &&
// 我們需要關注下面這一行
(first = tab[(n - 1) & hash]) != null) {
if (first.hash == hash && // always check first node
((k = first.key) == key || (key != null && key.equals(k))))
return first;
if ((e = first.next) != null) {
if (first instanceof TreeNode)
return ((TreeNode<K,V>)first).getTreeNode(hash, key);
do {
if (e.hash == hash &&
((k = e.key) == key || (key != null && key.equals(k))))
return e;
} while ((e = e.next) != null);
}
}
return null;
}我們看看程式碼中註釋下方的一行程式碼：first = tab[(n - 1) & hash])。
使用陣列長度減一 與運算 hash 值。這行程式碼就是為什麼要讓前面的 hash 方法移位並異或。
我們分析一下：
首先，假設有一種情況，物件 A 的 hashCode 為 1000010001110001000001111000000，物件 B 的 hashCode 為 0111011100111000101000010100000。
如果陣列長度是16，也就是 15 與運算這兩個數， 你會發現結果都是0。這樣的雜湊結果太讓人失望了。很明顯不是一個好的雜湊演算法。
但是如果我們將 hashCode 值右移 16 位，也就是取 int 型別的一半，剛好將該二進位制數對半切開。並且使用位異或運算（如果兩個數對應的位置相反，則結果為1，反之為0），這樣的話，就能避免我們上面的情況的發生。
總的來說，使用位移 16 位和 異或 就是防止這種極端情況。但是，該方法在一些極端情況下還是有問題，比如：10000000000000000000000000 和 10000000001000000000000000 這兩個數，如果陣列長度是16，那麼即使右移16位，在異或，hash 值還是會重複。但是為了效能，對這種極端情況，JDK 的作者選擇了效能。畢竟這是少數情況，為了這種情況去增加 hash 時間，價效比不高。
HashMap 為什麼使用 & 與運算代替模運算？
我們再看看剛剛說的那個根據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。
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）。大大限制了雜湊的範圍。
我們自定義 HashMap 容量最好是多少？
那我們如何自定義呢？自從有了阿里的規約外掛，每次樓主都要初始化容量，如果我們預計我們的散列表中有2個數據，那麼我就初始化容量為2嘛？
絕對不行，如果大家看過原始碼就會發現，如果Map中已有資料的容量達到了初始容量的 75%，那麼散列表就會擴容，而擴容將會重新將所有的資料重新雜湊，效能損失嚴重，所以，我們可以必須要大於我們預計資料量的 1.34 倍，如果是2個數據的話，就需要初始化 2.68 個容量。當然這是開玩笑的，2.68 不可以，3 可不可以呢？肯定也是不可以的，我前面說了，如果不是2的冪次方，雜湊結果將會大大下降。導致出現大量連結串列。那麼我可以將初始化容量設定為4。 當然了，如果你預計大概會插入 12 條資料的話，那麼初始容量為16簡直是完美，一點不浪費，而且也不會擴容。
如果某個map很大，注意，肯定是事先沒有定義好初始化長度，假設，某個Map儲存了10000個數據，那麼他會擴容到 20000，實際上，根本不用 20000，只需要 10000* 1.34= 13400 個，然後向上找到一個2 的冪次方，也就是 16384 初始容量足夠。
貼個Hotpot虛擬機器生成hash雜湊值的實現：
static inline intptr_t get_next_hash(Thread * Self, oop obj) {
intptr_t value = 0 ;
if (hashCode == 0) {
// This form uses an unguarded global Park-Miller RNG,
// so it's possible for two threads to race and generate the same RNG.
// On MP system we'll have lots of RW access to a global, so the
// mechanism induces lots of coherency traffic.
value = os::random() ;
} else
if (hashCode == 1) {
// This variation has the property of being stable (idempotent)
// between STW operations. This can be useful in some of the 1-0
// synchronization schemes.
intptr_t addrBits = intptr_t(obj) >> 3 ;
value = addrBits ^ (addrBits >> 5) ^ GVars.stwRandom ;
} else
if (hashCode == 2) {
value = 1 ; // for sensitivity testing
} else
if (hashCode == 3) {
value = ++GVars.hcSequence ;
} else
if (hashCode == 4) {
value = intptr_t(obj) ;
} else {
// Marsaglia's xor-shift scheme with thread-specific state
// This is probably the best overall implementation -- we'll
// likely make this the default in future releases.
unsigned t = Self->_hashStateX ;
t ^= (t << 11) ;
Self->_hashStateX = Self->_hashStateY ;
Self->_hashStateY = Self->_hashStateZ ;
Self->_hashStateZ = Self->_hashStateW ;
unsigned v = Self->_hashStateW ;
v = (v ^ (v >> 19)) ^ (t ^ (t >> 8)) ;
Self->_hashStateW = v ;
value = v ;
}
value &= markOopDesc::hash_mask;
if (value == 0) value = 0xBAD ;
assert (value != markOopDesc::no_hash, "invariant") ;
TEVENT (hashCode: GENERATE) ;
return value;
}