有效和正確定義hashCode()和equals()
級別：入門級
Brian Goetz (brian@quiotix.com)
Quiotix Corp首席顧問
2003年 8 月
每個Java對象都有hashCode()和 equals()方法。許多類忽略（Override)這些方
法的缺省實施,以在對象實例之間提供更深層次的語義可比性。在Java理念和實踐
這一部分，Java開發人員Brian Goetz向您介紹在創建Java類以有效和準確定義
hashCode()和equals()時應遵循的規則和指南。您可以在討論論壇與作者和其它
讀者一同探討您對本文的看法。(您還可以點擊本文頂部或底部的討論進入論壇。
)
雖然Java語言不直接支持關聯數組 -- 可以使用任何對象作為一個索引的數組 --
但在根Object類中使用hashCode()方法明確表示期望廣泛使用HashMap(及其前輩
Hashtable)。理想情況下基于散列的容器提供有效插入和有效檢索；直接在對象
模式中支持散列可以促進基于散列的容器的開發和使用。
定義對象的相等性
Object類有兩種方法來推斷對象的標識：equals()和hashCode()。一般來說，如
果您忽略了其中一種，您必須同時忽略這兩種，因為兩者之間有必須維持的至關
重要的關系。特殊情況是根據equals() 方法，如果兩個對象是相等的，它們必須
有相同的hashCode()值(盡管這通常不是真的)。
特定類的equals()的語義在Implementer的左側定義；定義對特定類來說equals()
意味著什么是其設計工作的一部分。Object提供的缺省實施簡單引用下面等式：
??public boolean equals(Object obj) { return (this == obj); }
在這種缺省實施情況下，只有它們引用真正同一個對象時這兩個引用才是相等的
。同樣，Object提供的hashCode()的缺省實施通過將對象的內存地址對映于一個
整數值來生成。由于在某些架構上，地址空間大于int值的范圍，兩個不同的對象
有相同的hashCode()是可能的。如果您忽略了hashCode()，您仍舊可以使用
System.identityHashCode()方法來接入這類缺省值。
忽略 equals() -- 簡單實例
缺省情況下，equals()和hashCode()基于標識的實施是合理的，但對于某些類來
說，它們希望放寬等式的定義。例如，Integer類定義equals() 與下面類似：
??public boolean equals(Object obj) {
????return (obj instanceof Integer
????????????&& intValue() == ((Integer) obj).intValue());
??}
在這個定義中，只有在包含相同的整數值的情況下這兩個Integer對象是相等的。
結合將不可修改的Integer，這使得使用Integer作為HashMap中的關鍵字是切實可
行的。這種基于值的Equal方法可以由Java類庫中的所有原始封裝類使用，如
Integer、Float、Character和Boolean以及String(如果兩個String對象包含相同
順序的字符，那它們是相等的)。由于這些類都是不可修改的并且可以實施
hashCode()和equals()，它們都可以做為很好的散列關鍵字。
為什么忽略 equals()和hashCode()?
如果Integer不忽略equals() 和 hashCode()情況又將如何?如果我們從未在
HashMap或其它基于散列的集合中使用Integer作為關鍵字的話，什么也不會發生
。但是，如果我們在HashMap中使用這類Integer對象作為關鍵字，我們將不能夠
可*地檢索相關的值，除非我們在get()調用中使用與put()調用中極其類似的
Integer實例。這要求確保在我們的整個程序中，只能使用對應于特定整數值的
Integer對象的一個實例。不用說，這種方法極不方便而且錯誤頻頻。
Object的interface contract要求如果根據 equals()兩個對象是相等的，那么它
們必須有相同的hashCode()值。當其識別能力整個包含在equals()中時，為什么
我們的根對象類需要hashCode()？hashCode()方法純粹用于提高效率。Java平臺
設計人員預計到了典型Java應用程序中基于散列的集合類（Collection Class)的
重要性--如Hashtable、HashMap和HashSet，并且使用equals()與許多對象進行比
較在計算方面非常昂貴。使所有Java對象都能夠支持 hashCode()并結合使用基于
散列的集合，可以實現有效的存儲和檢索。
實施equals()和hashCode()的需求
實施equals()和 hashCode()有一些限制，Object文件中列舉出了這些限制。特別
是equals()方法必須顯示以下屬性：
Symmetry：兩個引用，a和 b,a.equals(b) if and only if b.equals(a)
Reflexivity：所有非空引用， a.equals(a)
Transitivity：If a.equals(b) and b.equals(c), then a.equals(c)
Consistency with hashCode()：兩個相等的對象必須有相同的hashCode()值
Object的規范中并沒有明確要求equals()和 hashCode() 必須一致 -- 它們的結
果在隨后的調用中將是相同的，假設“不改變對象相等性比較中使用的任何信息
?！边@聽起來象“計算的結果將不改變，除非實際情況如此?！边@一模糊聲明通
常解釋為相等性和散列值計算應是對象的可確定性功能，而不是其它。
對象相等性意味著什么？
人們很容易滿足Object類規范對equals() 和 hashCode() 的要求。決定是否和如
何忽略equals()除了判斷以外，還要求其它。在簡單的不可修值類中，如
Integer(事實上是幾乎所有不可修改的類)，選擇相當明顯 -- 相等性應基于基本
對象狀態的相等性。在Integer情況下，對象的唯一狀態是基本的整數值。
對于可修改對象來說，答案并不總是如此清楚。equals() 和hashCode() 是否應
基于對象的標識(象缺省實施)或對象的狀態(象Integer和String)？沒有簡單的答
案 -- 它取決于類的計劃使用。對于象List和Map這樣的容器來說，人們對此爭論
不已。Java類庫中的大多數類，包括容器類，錯誤出現在根據對象狀態來提供
equals()和hashCode()實施。
如果對象的hashCode()值可以基于其狀態進行更改，那么當使用這類對象作為基
于散列的集合中的關鍵字時我們必須注意，確保當它們用于作為散列關鍵字時，
我們并不允許更改它們的狀態。所有基于散列的集合假設，當對象的散列值用于
作為集合中的關鍵字時它不會改變。如果當關鍵字在集合中時它的散列代碼被更
改，那么將產生一些不可預測和容易混淆的結果。實踐過程中這通常不是問題 --
我們并不經常使用象List這樣的可修改對象做為HashMap中的關鍵字。
一個簡單的可修改類的例子是Point，它根據狀態來定義equals()和hashCode()。
如果兩個Point 對象引用相同的(x, y)座標，Point的散列值來源于x和y座標值的
IEEE 754-bit表示，那么它們是相等的。
對于比較復雜的類來說，equals()和hashCode()的行為可能甚至受到superclass
或interface的影響。例如，List接口要求如果并且只有另一個對象是List，而且
它們有相同順序的相同的Elements(由Element上的Object.equals() 定義)，List
對象等于另一個對象。hashCode()的需求更特殊--list的hashCode()值必須符合
以下計算：
??hashCode = 1;
??Iterator i = list.iterator();
??while (i.hasNext()) {
??????Object obj = i.next();
??????hashCode = 31*hashCode + (obj==null ? 0 : obj.hashCode());
??}
不僅僅散列值取決于list的內容，而且還規定了結合各個Element的散列值的特殊
算法。(String類規定類似的算法用于計算String的散列值。)
編寫自己的equals()和hashCode()方法
忽略缺省的equals()方法比較簡單，但如果不違反對稱（Symmetry）或傳遞性
（Transitivity）需求，忽略已經忽略的equals() 方法極其棘手。當忽略
equals()時，您應該總是在equals()中包括一些Javadoc注釋，以幫助那些希望能
夠正確擴展您的類的用戶。
作為一個簡單的例子，考慮以下類：
??class A {
????final B someNonNullField;
????C someOtherField;
????int someNonStateField;
??}
我們應如何編寫該類的equals()的方法？這種方法適用于許多情況：
??public boolean equals(Object other) {
????// Not strictly necessary, but often a good optimization
????if (this == other)
??????return true;
????if (!(other instanceof A))
??????return false;
????A otherA = (A) other;
????return
??????(someNonNullField.equals(otherA.someNonNullField))
????????&& ((someOtherField == null)
????????????? otherA.someOtherField == null
????????????: someOtherField.equals(otherA.someOtherField)));
??}
現在我們定義了equals()，我們必須以統一的方法來定義hashCode()。一種統一
但并不總是有效的定義hashCode()的方法如下：
??public int hashCode() { return 0; }
這種方法將生成大量的條目并顯著降低HashMaps的性能，但它符合規范。一個更
合理的hashCode()實施應該是這樣：
??public int hashCode() {
????int hash = 1;
????hash = hash * 31 + someNonNullField.hashCode();
????hash = hash * 31
????????????????+ (someOtherField == null ? 0 :
someOtherField.hashCode());
????return hash;
??}
注意：這兩種實施都降低了類狀態字段的equals()或hashCode()方法一定比例的
計算能力。根據您使用的類，您可能希望降低superclass的equals()或hashCode
()功能一部分計算能力。對于原始字段來說，在相關的封裝類中有helper功能，
可以幫助創建散列值，如Float.floatToIntBits。
編寫一個完美的equals()方法是不現實的。通常，當擴展一個自身忽略了equals
()的instantiable類時，忽略equals()是不切實際的，而且編寫將被忽略的
equals()方法(如在抽象類中)不同于為具體類編寫equals()方法。關于實例以及
說明的更詳細信息請參閱Effective Java Programming Language Guide, Item 7
(參考資料) 。
有待改進?
將散列法構建到Java類庫的根對象類中是一種非常明智的設計折衷方法 -- 它使
使用基于散列的容器變得如此簡單和高效。但是，人們對Java類庫中的散列算法
和對象相等性的方法和實施提出了許多批評。java.util中基于散列的容器非常方
便和簡便易用，但可能不適用于需要非常高性能的應用程序。雖然其中大部分將
不會改變，但當您設計嚴重依賴于基于散列的容器效率的應用程序時必須考慮這
些因素，它們包括：
太小的散列范圍。使用int而不是long作為hashCode()的返回類型增加了散列沖突
的幾率。
糟糕的散列值分配。短strings和小型integers的散列值是它們自己的小整數，接
近于其它“鄰近”對象的散列值。一個循規導矩（Well-behaved）的散列函數將
在該散列范圍內更均勻地分配散列值。
無定義的散列操作。雖然某些類，如String和List，定義了將其Element的散列值
結合到一個散列值中使用的散列算法，但語言規范不定義將多個對象的散列值結
合到新散列值中的任何批準的方法。我們在前面編寫自己的equals()和hashCode
()方法中討論的List、String或實例類A使用的訣竅都很簡單，但算術上還遠遠不
夠完美。類庫不提供任何散列算法的方便實施，它可以簡化更先進的hashCode()
實施的創建。
當擴展已經忽略了equals()的 instantiable類時很難編寫equals()。當擴展已經
忽略了equals()的 instantiable類時，定義equals()的“顯而易見的”方式都不
能滿足equals()方法的對稱或傳遞性需求。這意味著當忽略equals()時，您必須
了解您正在擴展的類的結構和實施詳細信息，甚至需要暴露基本類中的機密字段
，它違反了面向對象的設計的原則。
結束語
通過統一定義equals()和hashCode()，您可以提升類作為基于散列的集合中的關
鍵字的使用性。有兩種方法來定義對象的相等性和散列值：基于標識，它是
Object提供的缺省方法；基于狀態，它要求忽略equals()和hashCode()。當對象
的狀態更改時如果對象的散列值發生變化，確信當狀態作為散列關鍵字使用時您
不允許更更改其狀態。
關于作者
Brian Goetz過去15年以來一直是專業軟件開發人員。他是Quiotix的首席顧問，
Quiotix是位于加利福尼亞 Los Altos的一家軟件開發和咨詢公司。參閱Brian在
流行行業出版物中已經出版和即將出版的文章?？梢酝ㄟ^brian@quiotix.com與
Brian聯系。
??
http://www.scjp.com.cn