覆寫equals方法必須覆寫hashCode方法,這條規則基本上每個Javaer都知道,這也是JDK API上反複說明的,不過為什麼要這樣做呢?這兩個方法之間有什麼關系呢?本建議就來解釋該問題,我們先來看如下代碼:


我們先來看b1,Person類的equals覆寫了,不再判斷兩個位址是否相等,而是根據人員的姓名來判斷兩個對象是否相等,是以不管我們的new Person(“張三”)産生了多少個對象,它們都是相等的。把“張三”對象放入List中,再檢查List中是否包含,那結果肯定是true了。
接着來看b2,我們把張三這個對象作為了Map的鍵(Key),放進去的對象是張三,檢查的對象還是張三,那應該和List的結果相同了,但是很遺憾,結果是false。原因何在呢?
原因就是HashMap的底層處理機制是以數組的方式儲存Map條目(Map Entry)的,這其中的關鍵是這個數組下标的處理機制:依據傳入元素hashCode方法的傳回值決定其數組的下标,如果該數組位置上已經有了Map條目,且與傳入的鍵值相等則不處理,若不相等則覆寫;如果數組位置沒有條目,則插入,并加入到Map條目的連結清單中。同理,檢查鍵是否存在也是根據哈希碼确定位置,然後周遊查找鍵值的。
接着深入探讨,那對象元素的hashCode方法傳回的是什麼值呢?它是一個對象的哈希碼,是由Object類的本地方法生成的,確定每個對象有一個哈希碼(這也是雜湊演算法的基本要求:任意輸入k,通過一定算法f(k),将其轉換為非可逆的輸出,對于兩個輸入k1和k2,要求若k1=k2,則必須f(k1)=f(k2),但也允許k1≠k2,f(k1)=f(k2)的情況存在)。
那回到我們的例子上,由于我們沒有重寫hashCode方法,兩個張三對象的hashCode方法傳回值(也就是哈希碼)肯定是不相同的了,在HashMap的數組中也就找不到對應的Map條目了,于是就傳回了false。
問題清楚了,修改也非常簡單,重寫一下hashCode方法即可,代碼如下:


其中HashCodeBuilder是org.apache.commons.lang.builder包下的一個哈希碼生成工具,使用起來非常友善,諸位可以直接在項目中內建。(為什麼不直接寫hashCode方法?因為哈希碼的生成有很多種算法,自己寫麻煩,事兒又多,是以采用拿來主義是最好的方法。)
本文轉自SummerChill部落格園部落格,原文連結:http://www.cnblogs.com/DreamDrive/p/5431725.html,如需轉載請自行聯系原作者