Java中的hashcode方法介紹
哈希表這個(gè)數(shù)據(jù)結(jié)構(gòu)想必大多數(shù)人都不陌生,而且在很多地方都會(huì)利用到hash表來提高查找效率。在Java的Object類中有一個(gè)方法:
public native int hashCode();
根據(jù)這個(gè)方法的聲明可知,該方法返回一個(gè)int類型的數(shù)值,并且是本地方法,因此在Object類中并沒有給出具體的實(shí)現(xiàn)。
為何Object類需要這樣一個(gè)方法?它有什么作用呢?今天我們就來具體探討一下hashCode方法。
一.hashCode方法的作用
對于包含容器類型的程序設(shè)計(jì)語言來說,基本上都會(huì)涉及到hashCode。在Java中也一樣,hashCode方法的主要作用是為了配合基于散列的集合一起正常運(yùn)行,這樣的散列集合包括HashSet、HashMap以及HashTable。
為什么這么說呢?考慮一種情況,當(dāng)向集合中插入對象時(shí),如何判別在集合中是否已經(jīng)存在該對象了?(注意:集合中不允許重復(fù)的元素存在)
也許大多數(shù)人都會(huì)想到調(diào)用equals方法來逐個(gè)進(jìn)行比較,這個(gè)方法確實(shí)可行。但是如果集合中已經(jīng)存在一萬條數(shù)據(jù)或者更多的數(shù)據(jù),如果采用equals方法去逐一比較,效率必然是一個(gè)問題。此時(shí)hashCode方法的作用就體現(xiàn)出來了,當(dāng)集合要添加新的對象時(shí),先調(diào)用這個(gè)對象的hashCode方法,得到對應(yīng)的hashcode值,實(shí)際上在HashMap的具體實(shí)現(xiàn)中會(huì)用一個(gè)table保存已經(jīng)存進(jìn)去的對象的hashcode值,如果table中沒有該hashcode值,它就可以直接存進(jìn)去,不用再進(jìn)行任何比較了;如果存在該hashcode值, 就調(diào)用它的equals方法與新元素進(jìn)行比較,相同的話就不存了,不相同就散列其它的地址,所以這里存在一個(gè)沖突解決的問題,這樣一來實(shí)際調(diào)用equals方法的次數(shù)就大大降低了,說通俗一點(diǎn):Java中的hashCode方法就是根據(jù)一定的規(guī)則將與對象相關(guān)的信息(比如對象的存儲(chǔ)地址,對象的字段等)映射成一個(gè)數(shù)值,這個(gè)數(shù)值稱作為散列值。下面這段代碼是java.util.HashMap的中put方法的具體實(shí)現(xiàn):
public V put(K key, V value) {
if (key == null)
return putForNullKey(value);
int hash = hash(key.hashCode());
int i = indexFor(hash, table.length);
for (Entry<k,v> e = table[i]; e != null; e = e.next) {
Object k;
if (e.hash == hash && ((k = e.key) == key || key.equals(k))) {
V oldValue = e.value;
e.value = value;
e.recordAccess(this);
return oldValue;
}
}
modCount++;
addEntry(hash, key, value, i);
return null;
}
put方法是用來向HashMap中添加新的元素,從put方法的具體實(shí)現(xiàn)可知,會(huì)先調(diào)用hashCode方法得到該元素的hashCode值,然后查看table中是否存在該hashCode值,如果存在則調(diào)用equals方法重新確定是否存在該元素,如果存在,則更新value值,否則將新的元素添加到HashMap中。從這里可以看出,hashCode方法的存在是為了減少equals方法的調(diào)用次數(shù),從而提高程序效率。
有些朋友誤以為默認(rèn)情況下,hashCode返回的就是對象的存儲(chǔ)地址,事實(shí)上這種看法是不全面的,確實(shí)有些JVM在實(shí)現(xiàn)時(shí)是直接返回對象的存儲(chǔ)地址,但是大多時(shí)候并不是這樣,只能說可能存儲(chǔ)地址有一定關(guān)聯(lián)。下面是HotSpot JVM中生成hash散列值的實(shí)現(xiàn):
static inline intptr_t get_next_hash(Thread * Self, oop obj) {
intptr_t value = 0 ;
if (hashCode == 0) {
// This form uses an unguarded global Park-Miller RNG,
// so it's possible for two threads to race and generate the same RNG.
// On MP system we'll have lots of RW access to a global, so the
// mechanism induces lots of coherency traffic.
value = os::random() ;
} else
if (hashCode == 1) {
// This variation has the property of being stable (idempotent)
// between STW operations. This can be useful in some of the 1-0
// synchronization schemes.
intptr_t addrBits = intptr_t(obj) >> 3 ;
value = addrBits ^ (addrBits >> 5) ^ GVars.stwRandom ;
} else
if (hashCode == 2) {
value = 1 ; // for sensitivity testing
} else
if (hashCode == 3) {
value = ++GVars.hcSequence ;
} else
if (hashCode == 4) {
value = intptr_t(obj) ;
} else {
// Marsaglia's xor-shift scheme with thread-specific state
// This is probably the best overall implementation -- we'll
// likely make this the default in future releases.
unsigned t = Self->_hashStateX ;
t ^= (t << 11) ;
Self->_hashStateX = Self->_hashStateY ;
Self->_hashStateY = Self->_hashStateZ ;
Self->_hashStateZ = Self->_hashStateW ;
unsigned v = Self->_hashStateW ;
v = (v ^ (v >> 19)) ^ (t ^ (t >> 8)) ;
Self->_hashStateW = v ;
value = v ;
}
value &= markOopDesc::hash_mask;
if (value == 0) value = 0xBAD ;
assert (value != markOopDesc::no_hash, "invariant") ;
TEVENT (hashCode: GENERATE) ;
return value;
}
該實(shí)現(xiàn)位于hotspot/src/share/vm/runtime/synchronizer.cpp文件下。
因此有人會(huì)說,可以直接根據(jù)hashcode值判斷兩個(gè)對象是否相等嗎?肯定是不可以的,因?yàn)椴煌膶ο罂赡軙?huì)生成相同的hashcode值。雖然不能根據(jù)hashcode值判斷兩個(gè)對象是否相等,但是可以直接根據(jù)hashcode值判斷兩個(gè)對象不等,如果兩個(gè)對象的hashcode值不等,則必定是兩個(gè)不同的對象。如果要判斷兩個(gè)對象是否真正相等,必須通過equals方法。
也就是說對于兩個(gè)對象,如果調(diào)用equals方法得到的結(jié)果為true,則兩個(gè)對象的hashcode值必定相等;
如果equals方法得到的結(jié)果為false,則兩個(gè)對象的hashcode值不一定不同;
如果兩個(gè)對象的hashcode值不等,則equals方法得到的結(jié)果必定為false;
如果兩個(gè)對象的hashcode值相等,則equals方法得到的結(jié)果未知。
二.equals方法和hashCode方法
在有些情況下,程序設(shè)計(jì)者在設(shè)計(jì)一個(gè)類的時(shí)候?yàn)樾枰貙慹quals方法,比如String類,但是千萬要注意,在重寫equals方法的同時(shí),必須重寫hashCode方法。為什么這么說呢?
下面看一個(gè)例子:
package com.cxh.test1;
import java.util.HashMap;
import java.util.HashSet;
import java.util.Set;
class People{
private String name;
private int age;
public People(String name,int age) {
this.name = name;
this.age = age;
}
public void setAge(int age){
this.age = age;
}
@Override
public boolean equals(Object obj) {
// TODO Auto-generated method stub
return this.name.equals(((People)obj).name) && this.age== ((People)obj).age;
}
}
public class Main {
public static void main(String[] args) {
People p1 = new People("Jack", 12);
System.out.println(p1.hashCode());
HashMap<people, integer=""> hashMap = new HashMap<people, integer="">();
hashMap.put(p1, 1);
System.out.println(hashMap.get(new People("Jack", 12)));
}
}
在這里我只重寫了equals方法,也就說如果兩個(gè)People對象,如果它的姓名和年齡相等,則認(rèn)為是同一個(gè)人。
這段代碼本來的意愿是想這段代碼輸出結(jié)果為“1”,但是事實(shí)上它輸出的是“null”。為什么呢?原因就在于重寫equals方法的同時(shí)忘記重寫hashCode方法。
雖然通過重寫equals方法使得邏輯上姓名和年齡相同的兩個(gè)對象被判定為相等的對象(跟String類類似),但是要知道默認(rèn)情況下,hashCode方法是將對象的存儲(chǔ)地址進(jìn)行映射。那么上述代碼的輸出結(jié)果為“null”就不足為奇了。原因很簡單,p1指向的對象和
System.out.println(hashMap.get(new People(“Jack”, 12)));這句中的new People(“Jack”, 12)生成的是兩個(gè)對象,它們的存儲(chǔ)地址肯定不同。下面是HashMap的get方法的具體實(shí)現(xiàn):
public V get(Object key) {
if (key == null)
return getForNullKey();
int hash = hash(key.hashCode());
for (Entry<k,v> e = table[indexFor(hash, table.length)];
e != null;
e = e.next) {
Object k;
if (e.hash == hash && ((k = e.key) == key || key.equals(k)))
return e.value;
}
return null;
}
所以在hashmap進(jìn)行g(shù)et操作時(shí),因?yàn)榈玫降膆ashcdoe值不同(注意,上述代碼也許在某些情況下會(huì)得到相同的hashcode值,不過這種概率比較小,因?yàn)殡m然兩個(gè)對象的存儲(chǔ)地址不同也有可能得到相同的hashcode值),所以導(dǎo)致在get方法中for循環(huán)不會(huì)執(zhí)行,直接返回null。
因此如果想上述代碼輸出結(jié)果為“1”,很簡單,只需要重寫hashCode方法,讓equals方法和hashCode方法始終在邏輯上保持一致性。
package com.cxh.test1;
import java.util.HashMap;
import java.util.HashSet;
import java.util.Set;
class People{
private String name;
private int age;
public People(String name,int age) {
this.name = name;
this.age = age;
}
public void setAge(int age){
this.age = age;
}
@Override
public int hashCode() {
// TODO Auto-generated method stub
return name.hashCode()*37+age;
}
@Override
public boolean equals(Object obj) {
// TODO Auto-generated method stub
return this.name.equals(((People)obj).name) && this.age== ((People)obj).age;
}
}
public class Main {
public static void main(String[] args) {
People p1 = new People("Jack", 12);
System.out.println(p1.hashCode());
HashMap<people, integer=""> hashMap = new HashMap<people, integer="">();
hashMap.put(p1, 1);
System.out.println(hashMap.get(new People("Jack", 12)));
}
}
這樣一來的話,輸出結(jié)果就為“1”了。
下面這段話摘自Effective Java一書:
在程序執(zhí)行期間,只要equals方法的比較操作用到的信息沒有被修改,那么對這同一個(gè)對象調(diào)用多次,hashCode方法必須始終如一地返回同一個(gè)整數(shù)。
如果兩個(gè)對象根據(jù)equals方法比較是相等的,那么調(diào)用兩個(gè)對象的hashCode方法必須返回相同的整數(shù)結(jié)果。
如果兩個(gè)對象根據(jù)equals方法比較是不等的,則hashCode方法不一定得返回不同的整數(shù)。
對于第二條和第三條很好理解,但是第一條,很多時(shí)候就會(huì)忽略。在《Java編程思想》一書中的P495頁也有同第一條類似的一段話:
“設(shè)計(jì)hashCode()時(shí)最重要的因素就是:無論何時(shí),對同一個(gè)對象調(diào)用hashCode()都應(yīng)該產(chǎn)生同樣的值。如果在講一個(gè)對象用put()添加進(jìn)HashMap時(shí)產(chǎn)生一個(gè)hashCdoe值,而用get()取出時(shí)卻產(chǎn)生了另一個(gè)hashCode值,那么就無法獲取該對象了。所以如果你的hashCode方法依賴于對象中易變的數(shù)據(jù),用戶就要當(dāng)心了,因?yàn)榇藬?shù)據(jù)發(fā)生變化時(shí),hashCode()方法就會(huì)生成一個(gè)不同的散列碼”。
下面舉個(gè)例子:
package com.cxh.test1;
import java.util.HashMap;
import java.util.HashSet;
import java.util.Set;
class People{
private String name;
private int age;
public People(String name,int age) {
this.name = name;
this.age = age;
}
public void setAge(int age){
this.age = age;
}
@Override
public int hashCode() {
// TODO Auto-generated method stub
return name.hashCode()*37+age;
}
@Override
public boolean equals(Object obj) {
// TODO Auto-generated method stub
return this.name.equals(((People)obj).name) && this.age== ((People)obj).age;
}
}
public class Main {
public static void main(String[] args) {
People p1 = new People("Jack", 12);
System.out.println(p1.hashCode());
HashMap<people, integer=""> hashMap = new HashMap<people, integer="">();
hashMap.put(p1, 1);
p1.setAge(13);
System.out.println(hashMap.get(p1));
}
}
這段代碼輸出的結(jié)果為“null”,想必其中的原因大家應(yīng)該都清楚了。
因此,在設(shè)計(jì)hashCode方法和equals方法的時(shí)候,如果對象中的數(shù)據(jù)易變,則最好在equals方法和hashCode方法中不要依賴于該字段。
以上屬個(gè)人理解,如有不正之處,歡迎批評(píng)指正。
總結(jié)
以上就是本文關(guān)于Java中的hashcode方法介紹的全部內(nèi)容,希望對大家有所幫助。感興趣的朋友可以繼續(xù)參閱本站:Java中的靜態(tài)內(nèi)部類詳解及代碼示例、Java源碼解析之object類、java使用RandomAccessFile類基于指針讀寫文件實(shí)例代碼等,有什么問題可以隨時(shí)留言,小編會(huì)及時(shí)回復(fù)大家的。感謝朋友們對本站的支持!
相關(guān)文章
又又叕出BUG啦!理智分析Java NIO的ByteBuffer到底有多難用
網(wǎng)絡(luò)數(shù)據(jù)的基本單位永遠(yuǎn)是byte,Java NIO提供ByteBuffer作為字節(jié)的容器,但該類過于復(fù)雜,有點(diǎn)難用.本篇文章就帶大家簡單了解一下 ,需要的朋友可以參考下2021-06-06
Mybatis?List列表In查詢實(shí)現(xiàn)的注意事項(xiàng)說明
這篇文章主要介紹了Mybatis?List列表In查詢實(shí)現(xiàn)的注意事項(xiàng)說明,具有很好的參考價(jià)值,希望對大家有所幫助。如有錯(cuò)誤或未考慮完全的地方,望不吝賜教2022-02-02
關(guān)于解決雪花算法生成的ID傳輸前端后精度丟失問題
這篇文章主要介紹了關(guān)于解決雪花算法生成的ID傳輸前端后精度丟失問題,雪花算法生成的ID傳輸?shù)角岸藭r(shí),會(huì)出現(xiàn)后三位精度丟失,本文提供了解決思路,需要的朋友可以參考下2023-03-03
Mybatis中where標(biāo)簽與if標(biāo)簽結(jié)合使用詳細(xì)說明
mybatis中if和where用于動(dòng)態(tài)sql的條件拼接,在查詢語句中如果缺失某個(gè)條件,通過if和where標(biāo)簽可以動(dòng)態(tài)的改變查詢條件,下面這篇文章主要給大家介紹了關(guān)于Mybatis中where標(biāo)簽與if標(biāo)簽結(jié)合使用的詳細(xì)說明,需要的朋友可以參考下2023-03-03
@FeignClient?實(shí)現(xiàn)簡便http請求封裝方式
這篇文章主要介紹了@FeignClient?實(shí)現(xiàn)簡便http請求封裝方式,具有很好的參考價(jià)值,希望對大家有所幫助。如有錯(cuò)誤或未考慮完全的地方,望不吝賜教2022-03-03
Java接入微信支付超級(jí)詳細(xì)保姆級(jí)教程
這篇文章主要給大家介紹了關(guān)于Java接入微信支付的相關(guān)資料,包括l 準(zhǔn)備開發(fā)所需的賬號(hào)和配置信息、準(zhǔn)備環(huán)境、設(shè)置開發(fā)參數(shù)以及實(shí)現(xiàn)支付接口,回調(diào)地址的設(shè)置和異步回調(diào)通知的處理也是文章的重點(diǎn)內(nèi)容,需要的朋友可以參考下2024-12-12

