java HashMap hash方法分析

下面分別分析下，JDK1.7 與 JDK1.8 中 hash方法的運算過程，而且左後結合JDK1.8 中 hash方法來進行詳細說明。

 

JDK1.7 中HashMap 中hash table 定位算法： 

int hash = hash(key.hashCode()); 

int i = indexFor(hash, table.length);  

其中indexFor和hash源碼以下： 

/** * Applies a supplemental hash function to a given hashCode, which * defends against poor quality hash functions. This is critical * because HashMap uses power-of-two length hash tables, that * otherwise encounter collisions for hashCodes that do not differ * in lower bits. Note: Null keys always map to hash 0, thus index 0. */ static int hash(int h) { // This function ensures that hashCodes that differ only by // constant multiples at each bit position have a bounded // number of collisions (approximately 8 at default load factor). h ^= (h >>> 20) ^ (h >>> 12); return h ^ (h >>> 7) ^ (h >>> 4); } /** * Returns index for hash code h. */ static int indexFor(int h, int length) { return h & (length-1); }

indexFor這個方法論壇中已有人分析過，這裏就再也不分析。 

如今分析一下hash算法： 

Java代碼  

h ^= (h >>> 20) ^ (h >>> 12);  

return h ^ (h >>> 7) ^ (h >>> 4);  

假設key.hashCode()的值爲：0x7FFFFFFF，table.length爲默認值16。 
上面算法執行以下： 

 

獲得i=15 

其中h^(h>>>7)^(h>>>4) 結果中的位運行標識是把h>>>7 換成 h>>>8來看。 

即最後h^(h>>>8)^(h>>>4) 運算後hashCode值每位數值以下： 
8=8 
7=7^8 
6=6^7^8 
5=5^8^7^6 
4=4^7^6^5^8 
3=3^8^6^5^8^4^7 
2=2^7^5^4^7^3^8^6 
1=1^6^4^3^8^6^2^7^5 
結果中的一、二、3三位出現重複位^運算 
3=3^8^6^5^8^4^7     ->   3^6^5^4^7 
2=2^7^5^4^7^3^8^6   ->   2^5^4^3^8^6 
1=1^6^4^3^8^6^2^7^5 ->   1^4^3^8^2^7^5 

算法中是採用(h>>>7)而不是(h>>>8)的算法，應該是考慮一、二、3三位出現重複位^運算的狀況。使得最低位上原hashCode的8位都參與了^運算，因此在table.length爲默認值16的狀況下面，hashCode任意位的變化基本都能反應到最終hash table 定位算法中，這種狀況下只有原hashCode第3位高1位變化不會反應到結果中，即：0x7FFFF7FF的i=15。

----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

JDK1.8中hash方法已經獲得了簡化

static final int hash(Object key) { int h; return (key == null) ? 0 : (h = key.hashCode()) ^ (h >>> 16); }

而且針對HashMap中的hash算法，你們看的一臉懵逼。這段代碼叫「擾動函數」。

咱們知道，HashMap經過 (length - 1) & hash 的方式獲取table數組的下標，而且table的長度必須爲2 ^ n，由於這樣前面的公式就至關於取模。

若是咱們對key的hash不進行擾動，「與」操做的結果就是hashcode的高位所有歸0，只保留低位的值用來作數組下標訪問。以初始長度16爲例，16 - 1 = 15。2進製表示是00000000 00000000 00001111。和某散列值作「與」操做以下，結果就是借去了最低位的四位。

    10100101 11000100 00100101

&  00000000 00000000 00001111

---------------------------------------------

    00000000 00000000 00000101    // 高位所有歸0，只保留末四位

但這個時候問題就來了，這樣就算個人hashcode散列值再怎麼鬆散，要是隻取最後幾位的話，碰撞也會很嚴重。更要命的是若是散列自己作的很差，分佈上成等差數列的漏洞，剛好使最後幾個低位呈現規律性重複，就無比蛋疼。

這時候擾動函數的價值就體現出來了，咱們根據圖來分析JDK1.8 的hash方法如何擾動的

右移16位，正好是32bit的一半，本身的高半區和低半區做異或，就是混合原始哈希嗎的高位和低位，以此來加大低位的隨機性。而混合後的低位can澤勒高位的部分特徵，這樣高位的信息也被表象保留下來。

最後咱們來看一下Peter Lawley的一片專欄文章《An introduction to optimising a hashing strategy》裏的一個實驗：他隨機選取了352個字符串，在他們散列值徹底沒有衝突的前提下，對他們作低位掩碼，取數組下標。

結果顯示，當HashMap數組長度爲512的時候，也就是用掩碼取低九位的時候，在沒有擾動函數的狀況下，發生了103次碰撞，接近30%。而在使用了擾動函數後只有92次碰撞。碰撞減小了10%。看來擾動函數確實有功效的。

但明顯Java8 以爲擾動作一次就夠了，作4次的話，多了可能邊際效用也不大，所謂爲了效率就改爲了一次。

那爲何必需要用 ^ 作擾動呢？

由於異或運算，實現均衡分配獲得1或者0的機率都是1/2，而&（與）運算獲得0的機率較大爲75%，| (或)運算獲得1的機率較大爲75%。下面舉例:

對於0/1的運算組合無非就是下面四種，咱們分別作異或、與、或運算

    0   |   1   |   1   |   0

^  1   |   0   |   1   |   0 

---------------------------

    1       1       0       0

 

    0   |   1   |   1   |   0

&  1   |   0   |   1   |   0 

---------------------------

    0       0       1       0

 

    0   |   1   |   1   |   0

|   1   |   0   |   1   |   0 

---------------------------

    1       1       1       0

咱們能夠看到，對於不一樣狀況下的運算，只有異或運算表現出結果均勻，這也是爲何擾動運算要用異或的緣由了