原標(biāo)題：高效Java第九條覆蓋equals時總要覆蓋hashCode

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

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

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

如果兩個對象equals(Object)方法比較是相等的，那么調(diào)用這兩個對象的hashCode方法必須產(chǎn)生同樣的整數(shù)結(jié)果。

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

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

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

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

給PhoneNumber類提供一個適當(dāng)?shù)膆ashCode方法。下面的hashCode方法是錯誤的：

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

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

1.把某個非零的常數(shù)值，比如17，保存在一個名為result的int類型的變量中。2.對于對象中每個關(guān)鍵域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方法通過遞歸地調(diào)用equals方法來比較這個域，則同樣為這個域遞歸地調(diào)用hashCode。如果需要更復(fù)雜的比較，則為這個域計算一個范式，然后針對這個范式調(diào)用hashCode。如果這個域的值為null，則返回0(或者其他某個常數(shù)，但通常是0)。

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

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

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

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

PhoneNumber類的hashCode：

緩存散列碼

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

不要排除對象的關(guān)鍵部分

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

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

責(zé)任編輯：

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。