[ 轉載 ]hashCode及HashMap中的hash()函數

hashCode及HashMap中的hash()函數

 

1、hashcode是什麼

要理解hashcode首先要理解hash表這個概念

1. 哈希表

• hash表也稱散列表（Hash table），是根據關鍵碼值(Key value)而直接進行訪問的數據結構。也就是說，它經過把關鍵碼值映射到表中一個位置來訪問記錄，以加快查找的速度。這個映射函數叫作散列函數，存放記錄的數組叫作散列表。
• 給定表M，存在函數f(key)，對任意給定的關鍵字值key，代入函數後若能獲得包含該關鍵字的記錄在表中的地址，則稱表M爲哈希(Hash）表，函數f(key)爲哈希(Hash) 函數。
• 簡單理解就是：在記錄的存儲位置和它的關鍵字之間創建一個肯定的對應關係f，使每一個關鍵字和結構中一個惟一的存儲位置相對應。
• 具備快速查找和插入操做的優勢

2. hashcode

• hashcode 經過hash函數計算獲得，hashcode就是在hash表中有對應的位置
• 每一個對象都有hashcode，經過將對象的物理地址轉換爲一個整數，將整數經過hash計算就能夠獲得hashcode

---

 2、hashcode的做用

    HashCode的存在主要是爲了查找的快捷性，HashCode是用來在散列存儲結構中肯定對象的存儲地址的

    對於容器類設計 基本上都會涉及到hashCode。在Java中也同樣，hashCode方法的主要做用是爲了配合基於散列的集合一塊兒正常運行，這樣的散列集合包括HashSet、HashMap以及HashTable。

   在對集合進行插入操做時，集合內時是不容許存在重複元素的，這樣就引起了一個問題

   如何判別在集合中是否已經存在該對象了？

   首先想到的方法就是調用equals()方法，這個方法確實可行。可是若是集合中已經存在大量的數據或者更多的數據，若是採用equals方法去逐一比較，效率必然是一個問題。    此時hashCode方法的做用就體現出來了，當集合要添加新的對象時，先調用這個對象的hashCode方法，獲得對應的hashcode值，實際上在HashMap的具體實現中會一個表保存已經存進去的對象的hashcode值，若是table中沒有該hashcode值，它就能夠直接存進去，不用再進行任何比較了；若是存在該hashcode值， 就調用它的equals方法與新元素進行比較，相同的話就不存了，不相同就散列其它的地址，因此這裏存在一個衝突解決的問題，這樣一來實際調用equals方法的次數就大大下降了。

    這也就解釋了爲何equals()相等，則hashCode()必須相等。若是兩個對象equals()相等，則它們在哈希表(如HashSet、HashMap等)中只應該出現一次；若是hashCode()不相等，那麼它們會被散列到哈希表的不一樣位置，哈希表中出現了不止一次。

            因此說hashCode方法的存在是爲了減小equals方法的調用次數，從而提升程序效率。

---

 3、 hashCode()和equals()

Java的基類Object中的 equals()方法用於判斷兩個對象是否相等，hashCode()方法用於計算對象的哈希碼。equals()和hashCode()都不是final方法，均可以被重寫(overwrite)

1. equals方法

• Object類中equals()方法實現以下

• public boolean equals(Object obj) {
      return (this == obj);
  }

• 經過該實現能夠看出，Object類的實現採用了區分度最高的算法，即只要兩個對象不是同一個對象，那麼equals()必定返回false。

• 雖然能夠重寫equals()方法，可是有一些注意事項；JDK中說明了實現equals()方法應該遵照的約定

  • 自反性：x.equals(x)必須返回true。
  • 對稱性：x.equals(y)與y.equals(x)的返回值必須相等。
  • 傳遞性：x.equals(y)爲true，y.equals(z)也爲true，那麼x.equals(z)必須爲true。
  • 一致性：若是對象x和y在equals()中使用的信息都沒有改變，那麼x.equals(y)值始終不變。
  • 非null：x不是null，y爲null，則x.equals(y)必須爲false。

2. hashCode 方法

• Object類中hashCode()方法的聲明以下：

  public native int hashCode();

• 能夠看出，hashCode()是一個native方法，並且返回值類型是整形；實際上，該native方法將對象在內存中的地址做爲哈希碼返回，能夠保證不一樣對象的返回值不一樣。

• 與equals()方法相似，hashCode()方法能夠被重寫。JDK中對hashCode()方法的做用，以及實現時的注意事項作了說明：

  • （1）hashCode()在哈希表中起做用，如java.util.HashMap。
  • （2）若是對象在equals()中使用的信息都沒有改變，那麼hashCode()值始終不變。
  • （3）若是兩個對象使用equals()方法判斷爲相等，則hashCode()方法也應該相等。
  • （4）若是兩個對象使用equals()方法判斷爲不相等，則不要求hashCode()也必須不相等；可是開發人員應該認識到，不相等的對象產生不相同的hashCode能夠提升哈希表的性能。

• 重寫hashcode()的原則

  • （1）若是重寫了equals()方法，檢查條件「兩個對象使用equals()方法判斷爲相等，則hashCode()方法也應該相等」是否成立，若是不成立，則重寫hashCode ()方法。
  • （2）hashCode()方法不能太過簡單，不然哈希衝突過多。
  • （3）hashCode()方法不能太過複雜，不然計算複雜度太高，影響性能

• hashCode()重寫方法

  《Effective Java》中提出了一種簡單通用的hashCode算法：

  1. 初始化一個整形變量，爲此變量賦予一個非零的常數值，好比int result = 17;

  2. 選取equals方法中用於比較的全部域（之因此只選擇equals()中使用的域，是爲了保證上述原則的第1條），而後針對每一個域的屬性進行計算：

     (1) 若是是boolean值，則計算f ? 1:0
     (2) 若是是bytecharshortint,則計算(int)f
     (3) 若是是long值，則計算(int)(f ^ (f >>> 32))
     (4) 若是是float值，則計算Float.floatToIntBits(f)
     (5) 若是是double值，則計算Double.doubleToLongBits(f)，而後返回的結果是long,再用規則(3)去處理long,獲得int
     (6) 若是是對象應用，若是equals方法中採起遞歸調用的比較方式，那麼hashCode中一樣採起遞歸調用hashCode的方式。不然須要爲這個域計算一個範式，好比當這個域的值爲null的時候，那麼hashCode 值爲0
     (7) 若是是數組，那麼須要爲每一個元素當作單獨的域來處理。java.util.Arrays.hashCode方法包含了8種基本類型數組和引用數組的hashCode計算，算法同上。 

  3. 最後，把每一個域的散列碼合併到對象的哈希碼中。

---

 4、HashMap中的hash()函數

• HashMap中並無直接使用KV中K原有的hash值; 在HashMap的put、get操做時也未直接使用K中原有的hash值，而使用了一個hash()方法。讓咱們一塊兒看一下這個方法

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

• 這段代碼相似做用是爲了增長hashcode的隨機性

• key.hashCode()的做用是返回鍵值key所屬類型自帶的hashcode，返回的類型是int，若是直接拿散列值做爲下標訪問HashMap的主數組的話，考慮到int類型值的範圍[-2^31 , 2^31 -1]，雖然只要hash表映射比較鬆散的話，碰撞概率很小，可是映射空間太大，內存放不下，因此先作對數組的長度取模運算，獲得的餘數才能用來訪問數組下標。

• hashMap源碼中模運算是在這個indexFor( )函數裏完成的把散列值和數組長度-1作一個"與"操做

  static int indexFor(int h, int length) { return h & (length-1);}

  • 這也正好解釋了爲何HashMap的數組長度要取2的整數冪。由於數組長度-1至關於一個「低位掩碼」。「與」操做的結果就是散列值的高位所有歸零，只保留低位值.以初始長度16爲例，16-1=15。2進製表示是00000000 00000000 00001111。和某散列值作「與」操做以下，結果就是截取了最低的四位值。h & (length - 1) 和 h % length，它倆是等價不等效的，明顯位運算效率很是高。

  •   01111010 00111100 00100101
    & 00000000 00000000 00001111
    ----------------------------------
      00000000 00000000 00000101
      //高位所有歸零，只保留末四位 

  • but 只取後四位，即便散列值分佈再鬆散，碰撞概率仍是很大。更糟糕的是若是散列函數作的比較差吧，分佈上成個等差數列啥的，剛好使最後幾個低位呈現規律性重複，就比較蛋疼。

  • 這時候 「hash」函數做用就出來了

    • 右位移16位，正好是32bit的一半，高半區和低半區作異或，就是爲了混合原始哈希碼的高位和低位，以此來加大低位的隨機性。並且混合後的低位摻雜了高位的部分特徵，這樣高位的信息也被變相保留下來。
    • 設計者考慮到如今的hashCode分佈的已經很不錯了，並且當發生較大碰撞時也用樹形存儲下降了衝突。僅僅異或一下，少了系統的開銷，也不會形成由於高位沒有參與下標的計算(table長度比較小時)，從而引發的碰撞。
    • 根據研究結果顯示，當HashMap數組長度爲512的時候，也就是用掩碼取低9位的時候，在沒有使用hash()的狀況下，發生了103次碰撞，接近30%。而在使用了hash()以後只有92次碰撞。碰撞減小了將近10%。看來擾hash()函數在將下降碰撞上仍是有功效的。

• hashMap中 MAXIMUM_CAPACITY = 1 << 30;最大爲2的30次方（超過這個值就將threshold修改成Integer.MAX_VALUE（此時表的大小已是2的31次方了），代表不進行擴容了）