要理解hashcode首先要理解hash表這個概念java
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()不相等,那麼它們會被散列到哈希表的不一樣位置,哈希表中出現了不止一次。this
因此說hashCode方法的存在是爲了減小equals方法的調用次數,從而提升程序效率。spa
Java的基類Object中的 equals()方法用於判斷兩個對象是否相等,hashCode()方法用於計算對象的哈希碼。equals()和hashCode()都不是final方法,均可以被重寫(overwrite)設計
Object類中equals()方法實現以下code
public boolean equals(Object obj) { return (this == obj); }
經過該實現能夠看出,Object類的實現採用了區分度最高的算法,即只要兩個對象不是同一個對象,那麼equals()必定返回false。
雖然能夠重寫equals()方法,可是有一些注意事項;JDK中說明了實現equals()方法應該遵照的約定
Object類中hashCode()方法的聲明以下:
public native int hashCode();
能夠看出,hashCode()是一個native方法,並且返回值類型是整形;實際上,該native方法將對象在內存中的地址做爲哈希碼返回,能夠保證不一樣對象的返回值不一樣。
與equals()方法相似,hashCode()方法能夠被重寫。JDK中對hashCode()方法的做用,以及實現時的注意事項作了說明:
重寫hashcode()的原則
hashCode()重寫方法
《Effective Java》中提出了一種簡單通用的hashCode算法:
初始化一個整形變量,爲此變量賦予一個非零的常數值,好比int result = 17;
選取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計算,算法同上。
最後,把每一個域的散列碼合併到對象的哈希碼中。
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);}
01111010 00111100 00100101
& 00000000 00000000 00001111
----------------------------------
00000000 00000000 00000101
//高位所有歸零,只保留末四位
but 只取後四位,即便散列值分佈再鬆散,碰撞概率仍是很大。更糟糕的是若是散列函數作的比較差吧,分佈上成個等差數列啥的,剛好使最後幾個低位呈現規律性重複,就比較蛋疼。
這時候 「hash」函數做用就出來了
hashMap中 MAXIMUM_CAPACITY = 1 << 30;最大爲2的30次方(超過這個值就將threshold修改成Integer.MAX_VALUE(此時表的大小已是2的31次方了),代表不進行擴容了)