原標題：高效Java第九條覆蓋equals時總要覆蓋hashCode

高效Java第九條覆蓋equals時總要覆蓋hashCode

在每個覆蓋了equals方法的類中，也必須覆蓋hashCode方法。否則會導致該類無法與基于散列的集合一起正常運作。 hashCode約定

在應用程序的執行期間，只要對象的equals方法所用到的信息沒有被修改，那么對著同一個對象調用多次，hashCode方法都必須始終如一地返回同一個整數。

如果兩個對象equals(Object)方法比較是相等的，那么調用這兩個對象的hashCode方法必須產生同樣的整數結果。

如果兩個對象equals(Object)比較是不相等的，那么調用這兩個對象中的hashCode方法，則不一定要產生不同的整數結果。但是給不相等的對象產生截然不同的整數結果，有可能提高散列表的性能。 沒有覆蓋hashCode違反第二條約定

因沒有覆蓋hashCode而違反的關鍵約定是第二條：相等的對象必須具有相等的散列碼。 PhoneNumber例子——沒有覆蓋hashCode

該類無法與HashMap一起正常工作：

m.get(new PhoneNumber(408, 867, 5309))返回null。由于PhoneNumber類沒有覆蓋hashCode方法，從而導致兩個相等的實例具有不相等的散列碼，違反了hashCode的約定。因此，put方法把電話號碼對象存放在一個散列桶中，get方法卻在另一個散列桶中查找這個電話號碼。即使這兩個實例正好被放到同一個散列桶中，get方法也必定會返回null，因為HahsMsap有一項優化，可以將每個項相關聯的散列碼緩存起來，如果散列碼不匹配，也不必檢驗對象的等同性。

給PhoneNumber類提供一個適當的hashCode方法。下面的hashCode方法是錯誤的：

雖然上面的hashCode方法確保了相等的對象總是具有同樣的散列碼。但是它使得每個對象都具有同樣的散列碼。因此，每個對象都被映射到同一個散列桶中，使散列表退化為鏈表。它使得本該線性時間運行的程序變成了以平方級時間在運行。對于規模很大的散列表而言，這關系到散列表能否正常工作。 如何編寫好的散列函數

一個好的散列函數傾向于為不相等的對象產生不相等的散列碼。散列函數應該把集合中不相等的實例均勻地分布到所有可能的散列值上。

1.把某個非零的常數值，比如17，保存在一個名為result的int類型的變量中。2.對于對象中每個關鍵域f(指equals方法涉及的每個域)，完成以下步驟：a。為該域計算int類型的散列碼c:i.如果該域是boolean類型，則計算(f？1:0)。ii.如果該域是byte、char、short或者int類型，則計算(int)f。iii.如果該域是long類型，則計算(int)(f ^ (f >>> 32))。iv.如果該域是float類型，則計算Float.floatToIntBits(f)。v.如果該域是double類型，則計算Double.doubleToLongBits(f)，然后按照步驟2.a.iii，為得到的long類型值計算散列值。vi.如果該域是一個對象引用，并且該類的equals方法通過遞歸地調用equals方法來比較這個域，則同樣為這個域遞歸地調用hashCode。如果需要更復雜的比較，則為這個域計算一個范式，然后針對這個范式調用hashCode。如果這個域的值為null，則返回0(或者其他某個常數，但通常是0)。

vii.如果該域是一個數組，則要把每一個元素當做單獨的域來處理。遞歸地應用上述規則，對每個重要的元素計算一個散列碼，然后根據步驟2.b中的做法把這些散列值組合起來。如果數組域中的每個元素都很重要，建議使用Arrays.hashCode方法。b.把步驟2.a中計算得到的散列碼c合并到result中：result = 31 * result + c;3.返回result。

4.寫完了hashCode方法之后，問問自己“相等的實例是否都具有相等的散列碼”。建議編寫單元測試。

計算散列碼可以把冗余域排除在外。如果一個域的值可以根據參與計算的其他域的值計算出來，則可以把這樣的域排除在外。必須排除equals比較計算中沒有用到的任何域，否則很有可能違反hashCode約定的第二條。

值17是任選的。步驟2.b中的乘法部分使得散列值依賴于域的順序，如果一個類中包含多個相似的域，這樣的乘法運算就會產生一個更好的散列函數。String的散列函數省略了乘法部分，那么只是字母順序不同的所有字符串就會有相同的散列碼。選擇31是因為它是一個奇素數。如果乘數是偶數，并且乘法溢出的話，信息就會丟失，因為與2相乘等價于移位運算。使用素數的好處并不很明顯，但習慣上都使用素數來計算散列結果。31可以利用移位和減法來代替乘法，可以得到更好的性能：31 * i == (i << 5) -i。JVM可以自動完成這種優化。 給PhoneNumber編寫好的hashCode

PhoneNumber類的hashCode：

緩存散列碼

不可變類如果計算散列碼的開銷比較大，就應該考慮把散列碼緩存在對象內部，而不是每次請求的時候都重新計算散列碼。如果類的大多數對象都會被用做散列鍵，就應該在創建實例的時候計算散列碼。否則，可以選擇“延遲初始化”散列碼，一直到hashCode被第一次調用的時候才初始化。PhoneNumber類的對象有可能會經常被作為散列鍵：

不要排除對象的關鍵部分

不要試圖從散列碼計算中排除掉一個對象的關鍵部分來提高性能。即使這樣得到的散列函數運行起來更快，但是它的效果不見得會好，可能會導致散列表慢到根本無法使用。在實踐中，散列函數可能面臨大量的實例，在選擇忽略的區域之中，這些實例區別非常大。散列函數會把所有這些實例映射到極少數的散列碼上，基于散列的集合將會顯示出平方級的性能指標。JDK2之前的String散列函數至多只檢查16個字符，從第一個字符開始，在整個字符串中均勻選取。對于大型集合，該散列函數表現出了病態行為。 不要規定散列函數的細節

Java平臺類庫中的許多類，String、Integer、Date等都可以把hashCode方法返回的確切值規定為該實例值的一個函數。但是這并不是一個好注意,這會嚴格地限制了在將來的版本中改進散列函數的能力。如果沒有規定散列函數的細節，那么當你發現了它的內部缺陷時，就可以在后面的發行版本中修正它，確信沒有任何客戶端會依賴于散列函數返回的確切值。返回搜狐，查看更多

責任編輯：

總結

以上是生活随笔為你收集整理的java延迟覆盖_高效Java第九条覆盖equals时总要覆盖hashCode的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。