HashMap的hash()

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

/**
     * 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下標的計算有關。

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長度比較小時)，從而引發的碰撞。

HashMap#tableSizeFor()

源碼：

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的狀況。 
第一次右移

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 。 
第三次右移

n |= n >>> 4;

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

這個算法着實牛逼啊！

注意，獲得的這個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