HashMap的hash()

爲何要有HashMap的hash()方法,難道不能直接使用KV中K原有的hash值嗎?在HashMap的put、get操做時爲何不能直接使用K中原有的hash值。html

/**
     * Computes key.hashCode() and spreads (XORs) higher bits of hash * to lower. Because the table uses power-of-two masking, sets of * hashes that vary only in bits above the current mask will * always collide. (Among known examples are sets of Float keys * holding consecutive whole numbers in small tables.) So we * apply a transform that spreads the impact of higher bits * downward. There is a tradeoff between speed, utility, and * quality of bit-spreading. Because many common sets of hashes * are already reasonably distributed (so don't benefit from * spreading), and because we use trees to handle large sets of * collisions in bins, we just XOR some shifted bits in the * cheapest possible way to reduce systematic lossage, as well as * to incorporate impact of the highest bits that would otherwise * never be used in index calculations because of table bounds. */ static final int hash(Object key) { int h;  return (key == null) ? 0 : (h = key.hashCode()) ^ (h >>> 16); }

從上面的代碼能夠看到key的hash值的計算方法。key的hash值高16位不變,低16位與高16位異或做爲key的最終hash值。(h >>> 16,表示無符號右移16位,高位補0,任何數跟0異或都是其自己,所以key的hash值高16位不變。) 
這裏寫圖片描述 
爲何要這麼幹呢? 
這個與HashMap中table下標的計算有關。java

n = table.length; index = (n-1) & hash;

由於,table的長度都是2的冪,所以index僅與hash值的低n位有關,hash值的高位都被與操做置爲0了。 
假設table.length=2^4=16。 
這裏寫圖片描述 
由上圖能夠看到,只有hash值的低4位參與了運算。 
這樣作很容易產生碰撞。設計者權衡了speed, utility, and quality,將高16位與低16位異或來減小這種影響。設計者考慮到如今的hashCode分佈的已經很不錯了,並且當發生較大碰撞時也用樹形存儲下降了衝突。僅僅異或一下,既減小了系統的開銷,也不會形成的由於高位沒有參與下標的計算(table長度比較小時),從而引發的碰撞。git

HashMap#tableSizeFor()

源碼:github

static final int MAXIMUM_CAPACITY = 1 << 30; /** * Returns a power of two size for the given target capacity. */ static final int tableSizeFor(int cap) { int n = cap - 1; n |= n >>> 1; n |= n >>> 2; n |= n >>> 4; n |= n >>> 8; n |= n >>> 16; return (n < 0) ? 1 : (n >= MAXIMUM_CAPACITY) ? MAXIMUM_CAPACITY : n + 1; }

這個方法被調用的地方:算法

public HashMap(int initialCapacity, float loadFactor) { /**省略此處代碼**/ this.loadFactor = loadFactor; this.threshold = tableSizeFor(initialCapacity); }

由此能夠看到,當在實例化HashMap實例時,若是給定了initialCapacity,因爲HashMap的capacity都是2的冪,所以這個方法用於找到大於等於initialCapacity的最小的2的冪(initialCapacity若是就是2的冪,則返回的仍是這個數)。 
下面分析這個算法: 
首先,爲何要對cap作減1操做。int n = cap - 1; 
這是爲了防止,cap已是2的冪。若是cap已是2的冪, 又沒有執行這個減1操做,則執行完後面的幾條無符號右移操做以後,返回的capacity將是這個cap的2倍。若是不懂,要看完後面的幾個無符號右移以後再回來看看。 
下面看看這幾個無符號右移操做: 
若是n這時爲0了(通過了cap-1以後),則通過後面的幾回無符號右移依然是0,最後返回的capacity是1(最後有個n+1的操做)。 
這裏只討論n不等於0的狀況。 
第一次右移markdown

n |= n >>> 1;

因爲n不等於0,則n的二進制表示中總會有一bit爲1,這時考慮最高位的1。經過無符號右移1位,則將最高位的1右移了1位,再作或操做,使得n的二進制表示中與最高位的1緊鄰的右邊一位也爲1,如000011xxxxxx。 
第二次右移數據結構

n |= n >>> 2;

注意,這個n已經通過了n |= n >>> 1; 操做。假設此時n爲000011xxxxxx ,則n無符號右移兩位,會將最高位兩個連續的1右移兩位,而後再與原來的n作或操做,這樣n的二進制表示的高位中會有4個連續的1。如00001111xxxxxx 。 
第三次右移app

n |= n >>> 4;

此次把已經有的高位中的連續的4個1,右移4位,再作或操做,這樣n的二進制表示的高位中會有8個連續的1。如00001111 1111xxxxxx 。 
以此類推 
注意,容量最大也就是32bit的正數,所以最後n |= n >>> 16; ,最多也就32個1,可是這時已經大於了MAXIMUM_CAPACITY ,因此取值到MAXIMUM_CAPACITY 。 
舉一個例子說明下吧。 
這裏寫圖片描述ide

這個算法着實牛逼啊!this

注意,獲得的這個capacity卻被賦值給了threshold。

this.threshold = tableSizeFor(initialCapacity);

開始覺得這個是個Bug,感受應該這麼寫:

this.threshold = tableSizeFor(initialCapacity) * this.loadFactor;

這樣才符合threshold的意思(當HashMap的size到達threshold這個閾值時會擴容)。 
可是,請注意,在構造方法中,並無對table這個成員變量進行初始化,table的初始化被推遲到了put方法中,在put方法中會對threshold從新計算,put方法的具體實現請看這篇博文。

參考資料

1.Java HashMap工做原理及實現 
2.Java7的HashMap初始化變化 
3.java HashMap

相關文章
相關標籤/搜索