Java技術架構 · 程式 ·

關於 equals 和 hashCode,看這一篇真的夠了

作者:CringKong

版權聲明:本文為博主原創文章,遵循 CC 4.0 BY-SA 版權協議,轉載請附上原文出處連結和本聲明。本文連結:
https://blog.csdn.net/CringKong/article/details/89429269

這幾天在嘗試手擼一個類似Lombok的註解式代碼生成工具,用過Lombok的小夥伴知道,Lombok可以通過註解自動幫我們生產equals()和hashCode()方法,因此我也想實現這個功能,但是隨著工作的深入,我發現其實自己對於equals()和hashCode()的理解,也處在一個很低級的階段。

因此痛定思痛,進行了一番深入學習,才敢來寫這篇博客。

1、equals在Java中含義

首先要解釋清楚這個,equals方法在Java中代表邏輯上的相等,什麼叫邏輯上的相等?這個就涉及到Java本身的語法特性。

我們知道,Java中存在著==來判斷基本數據類型的相等,但是對於對象,==只能判斷內存地址是否相等,也就是說是否是同一個對象

int a = 10000;int b = 10000;// 對於基本數據類型, == 可以判斷邏輯上的相等System.out.println(a == b);Integer objA = 10000;Integer objB = 10000;Integer objA1 = objA;// 對於類實例, == 只能判斷是否為同一個實例(可以視為內存地址是否相等)System.out.println(objA == objB);System.out.println(objA == objA1);

註:這裡我們不討論Integer對於-128~127的緩存機制。

結果顯而易見:

隨著工作的深入,我發現其實自己對於equals()和hashCode()

但是明明 objA和objB邏輯上是相等的,憑什麼你就返回false?這時就誕生了一種需求,對於Java中的對象,要判斷邏輯相等,該怎麼實現呢,於是就出現了equals()方法。

Integer objA = 10000;Integer objB = 10000;Integer objA1 = objA;// 對於對象實例, equals 可以判斷兩個對象是否邏輯相等 System.out.println(objA.equals(objB));

Integer類已經重寫了equals()方法,所以結果也顯而易見:

equals()和hashCode()方法,因此我也想實現這個功能,但是

因此如果我們自己創建一個類的話, 要實現判斷兩個實例邏輯上是否相等,就需要重寫他的equals()方法。

// 重寫了equals方法的類static class GoodExample { private String name; private int age; public GoodExample(String name, int age) { this.name = name; this.age = age; } @Override public boolean equals(Object o) { if (this == o) return true; if (o == null || getClass() != o.getClass()) return false; GoodExample that = (GoodExample) o; return age == that.age && Objects.equals(name, that.name); }}// 沒有重寫euqals方法的類static class BadExample { private String nakeName; private int age; public BadExample(String nakeName, int age) { this.nakeName = nakeName; this.age = age; }}public static void main(String[] args) { System.out.println(new GoodExample("Richard", 36). equals(new GoodExample("Richard", 36))); System.out.println(new BadExample("Richard", 36). equals(new BadExample("Richard", 36)));}

相信你已經知道結果是什麼了:

具,用過Lombok的小夥伴知道,Lombok可以通過註解自動幫我們生產

2、hashCode在Java中的作用

網上有很多博客都把hashCode()和equals()混為一談,但實際上hashCode()就是他的字面意思,代表這個對象的哈希碼。

但是為什麼JavaDoc明確的告訴我們,hashCode()和equals()要一起重寫呢?原因是因為,在Java自帶的容器HashMap和HashSet中,都需同時要用到對象的hashCode()和equals()方法來進行判斷,然後再插入刪除元素,這點我們一會再談。

那麼我們還是單獨來看hashCode(),為什麼HashMap需要用到hashCode?這個就涉及到HashMap底層的數據結構 – 散列表的原理:

這幾天在嘗試手擼一個類似Lombok的註解式代碼生成工

HashMap底層用於存儲數據的結構其實是散列表(也叫哈希表),散列表是通過哈希函數將元素映射到數組指定下標位置,在Java中,這個哈希函數其實就是hashCode()方法。

舉個例子:

HashMap<String,GoodExample> map = new HashMap<>();map.put("cringkong",new GoodExample("jack",10));map.put("cricy",new GoodExample("lisa",12));System.out.println(map.get("cricy"));

在存入HashMap的時候,HashMap會用字符串"cringkong"和"cricy"的hashCode()去映射到數組指定下標位置,至於怎麼去映射,我們一會再說。

好了,現在我們明白了hashCode()為什麼被設計出來,那麼我們來進行一個實驗:

// 科學設計了hashCode的類static class GoodExample { private String name; private int age; public GoodExample(String name, int age) { this.name = name; this.age = age; } @Override public int hashCode() { return Objects.hash(name, age); }}// 不科學的hashCode寫法static class BadExample { private String nakeName; private int age; public BadExample(String nakeName, int age) { this.nakeName = nakeName; this.age = age; } @Override public int hashCode() { // 這裡我們沒有用 return nakeName.hashCode(); }}

這裡我們存在兩個類,GoodExample類通過類全部欄位進行hash運算得到hashCode,而BadExample只通過類的一個欄位進行hash運算,我們來看一下得到的結果:

System.out.println(new GoodExample("李老三", 22).hashCode());System.out.println(new GoodExample("李老三", 42).hashCode());System.out.println(new BadExample("王老五", 50).hashCode());System.out.println(new BadExample("王老五", 25).hashCode());
CringKong/article/details/89429269

可以看到,GoodExample的hashCode()標明了22歲和42歲的李老三是不同的,而BadExample卻認為50歲和25歲的王老五沒什麼分別。

那麼也就是說在HashMap中,兩個李老三會被放到不同的數組下標位置中,而兩個王老五會被放到同一個數組下標位置上。

PS : hashCode相等的兩個對象不一定邏輯相等,邏輯相等的兩個對象hashCode必須相等!

3、為什麼hashCode和equals要一起重寫

剛剛我們知道,equals()是用來判斷對象是否邏輯相等,hashCode()就是獲得一個對象的hash值,同時在HashMap中用來得到數組下標位置。

那麼為什麼很多地方很多人说到,hashCode()和equals()要一起重寫呢?明明通過對象hashCode就可以定位數組下標了啊,那我們直接用把對象存進去取出來不就行了嗎?

答案是這樣的:設計再良好的哈希函數,也會出現哈希衝突的情況,什麼是哈希衝突呢?舉個例子來說,我設計了這樣一種哈希函數:

 /** * 硬派哈希函數,哈希規則是 傳入的字符串的首位字符轉換成ASCII值 * * @param string 需要哈希的字符串 * @return 字符串的哈希值 */ private static int hardCoreHash(String string) { return string.charAt(0); }

我們來測試一下硬派哈希函數的哈希效果:

System.out.println(hardCoreHash("fish"));System.out.println(hardCoreHash("cat"));System.out.println(hardCoreHash("fuck"));
處連結和本聲明。本文連結:https://blogcsdnnet/

可以看到, "fish" 和 "fuck"出現了哈希衝突,這是我們不想看到的,一旦出現了哈希衝突,我們的哈希表就需要解決哈希衝突,一般解方式有:

  • 開發定址法(線性探測再散列,二次探測再散列,偽隨機探測再散列)
  • 再哈希法
  • 鏈地址法
  • 建立一個公共溢出區

這都是數據結構課本上的東西,我就不再細講了,不懂的同學自行搜索!

就像我之前說的,設計再精良的哈希函數,也會有哈希衝突的情況出現,Java中的hashCode()本身就是一種哈希函數,必然會出現哈希衝突,更怕一些程式設計師寫出某些硬派哈希函數。

既然存在哈希衝突,我們就得解決,HashMap採用的是鏈地址法來解決:(偷張圖…

博主原創文章,遵循CC40BY-SA版權協議,轉載請附上原文出

這裡就存在一種極端情況,如何判斷是究竟是兩個 邏輯相等的對象重複寫入,還是兩個邏輯不等的對象出現了哈希衝突呢?

很簡單,用equals()方法判斷不就完事了嗎,我們之前說了,equals()方法就是用來設計判斷兩個對象是否邏輯相等的啊!

我們來看一段HashCode簡單的取出key對應value的源碼:

作者:CringKong版權聲明:本文為

意思很簡單,先判斷這key的 hashCode是否相等,如果不相等,說明key和數組中對象一定邏輯不相等,就不用再判斷了,如果相等,就繼續判斷是否邏輯相等,從而確定究竟是出現了哈希衝突,還是確實就是要取這個key的對應的值。

所以說到這裡,你應該明白為什麼千叮嚀萬囑咐equals()和hashCode()要一塊重寫了吧。如果這個類的對象要作為HashMap的key,或者要存入HashSet,是必兩個方法都要重寫的,其他情況可以自行斟酌,但是為了安全方便不出錯,就直接一塊重寫了吧。

4、擴展:實現科學的哈希函數

說的科學的哈希函數,就不得不說經典的字符串哈希函數:DJB hash function俗稱Times33的哈希函數:

unsigned int time33(char *str){ unsigned int hash = 5381; while(*str){ hash += (hash << 5 ) + (*str++); } return (hash & 0x7FFFFFFF);}

這個函數的實現思路,就是不斷地讓當前的哈希值乘33(左移5位相當於乘上32,然後加上原值相當於乘上33),再加上字符串當前位置的值(ASCII),然後哈希值進入下一輪疊代,直到字符串的最後一位,疊代完成返回哈希值。

為什麼說他科學?因為根據實驗,這種方式得出來哈希值分布比較均勻,就是最小可能性出現哈希衝突,同時計算速度也比較快。

至於初始值5381怎麼來的?也是實驗找到的比較科學的一個數。(怎麼感覺說的跟廢話一樣?)

那麼Java中的hashCode()有沒有默認實現呢?當然有:

// Object類中的hashCode函數,是一個native方法,JVM實現public native int hashCode();

Object類作為所有類的父類,實現了native方法,是一個本地方法,JVM實現我們看不到。

而String類,則默認重寫了hashCode方法,我們看一下實現:

 public int hashCode() { // 初始值是0 int h = hash; if (h == 0 && value.length > 0) { char val[] = value; // 31作為乘子,是不是應該叫Timers31呢? for (int i = 0; i < value.length; i++) { h = 31 * h + val[i]; } hash = h; } return h; }

可以看到,Java選擇了31作為乘子,這也是有他的道理的,根據 Effective Java所說:

選擇數字31是因為它是一個奇質數,如果選擇一個偶數會在乘法運算中產生溢出,導致數值信息丟失,因為乘二相當於移位運算。選擇質數的優勢並不是特別的明顯,但以往的哈希算法都這樣做。同時,數字31有一個很好的特性,即乘法運算可以被移位和減法運算取代,來獲取更好的性能:31 * i == (i << 5) - i,現代的 Java 虛擬機可以自動的完成這個優化。

總結一下其實就是兩點原因:

  1. 奇質數作為哈希運算中的乘法因子,得到的哈希值效果比較好(分布均勻)
  2. JVM對於位運算的優化,最後選擇31是因為速度比較快

說這麼多,還是實驗出來的結果,Java開發人員認為這個數比較適合JVM平台。

當然也有大哥做了實驗:科普:為什麼 String hashCode 方法選擇數字31作為乘子

有興趣的小夥伴可以去看看。

而且Java本身也提供了一個工具類,就是之前我用到的java.util.Objects.hash()方法,我們來下他的實現方式:

public static int hashCode(Object a[]) { if (a == null) return 0; int result = 1; // 對於傳入的所有對象都進行一次Timers31 for (Object element : a) // 同時用到了每個對象的hashCode()方法 result = 31 * result + (element == null ? 0 : element.hashCode()); return result;}

總體思路還是一樣的。

聲明:文章觀點僅代表作者本人,PTTZH僅提供信息發布平台存儲空間服務。
喔!快樂的時光竟然這麼快就過⋯
more