原文鏈接：http://www.blogjava.net/jiangshachina/archive/2012/12/06/392569.html
關於Object類中的equals()方法與Comparable接口中的compareTo()方法之間有何種關聯，之前還真沒考慮過。通過java.net看到此文之後，收穫了一點兒新知識，希望大家也能如此。
方法equals()與Comparable接口中的compareTo()方法是Java中最基本的兩個方法之一，然而它們的定義卻圍繞着"與相等一致"這一有趣的概念。
equals()方法
Java中的equals()方法既明確，又模糊。Java清楚地定義瞭如何準確地檢驗一個equals()方法是可用的。一個恰當的equals()方法必須是自反的，對稱的，可傳遞的，一致的，並能處理null引用。
然而equals()方法又是不清晰的。Javadoc說到，該方法指定了其它對象是"等於"這個對象的。注意，"等於"是放在引號中的。此處的關鍵就是，它沒有定義如何去判定這種相等性。
·對象的一致性(==)默認是繼承自Object類
·對象的整體可觀測的狀態，例如，若兩個對象是相等的，那麼在應用的其它部分可以用一個對象去替代另一個對象。
·對象信息中的某些部分，如ID，使得檢驗對象相等性在邏輯上是有意義的。
compareTo()方法
Comparable接口定義了可比較性的概念。Javadoc指出compareTo()方法"強制設定了每個實現了該接口的類的對象的全部順序"。
實現了Comparable接口的類有一個天然的排序，這可便於存儲，也能在不使用單獨的Comparator的情況下，用於像TreeSet和TreeMap這樣的集合對象。
該接口的定義明晰，它要求其實現必須確保對稱性與傳遞性，就像equals()方法那樣。
一致性/非一致性相等
Comparable接口有如下描述：
類C的天然排序意味着要與equals()方法保持一致，只有當且僅當e1.compareTo(e2) == 0與e1.equals(e2)有相同的布爾值。
基本上，這就要求由compareTo()定義的相等性與equals()方法定義的相等性具有相同的概念(除去有null的情況)。乍一看，該要求很簡單，但實際上它有其複雜性，後面將會討論到。
當考慮到操作符重載時，這種定義就特別有用。若我們假設有一種類Java語言，在這種語言中，==並不表示對象的同一性，而是通過方法去進行比較，大於/小於操作符也是如此，問題是調什麼樣的方法。在類Java語言中大於/小於天然地就要基於compareTo()方法，而==則要調用equals()方法。
// our new Java-like languageif(a < b) return"Less"; // translation ignoring nulls: if (a.compareTo(b) < 0)if(a > b) return"Greater"; // translation ignoring nulls: if (a.compareTo(b) > 0)if(a == b) return"Equal"; // translation ignoring nulls: if (a.equals(b))thrownewException("Impossible assuming no nulls?"); |
但如果compareTo()方法不是"一致性相等"，那麼上述代碼將會拋出異常，因爲當a.equals(b)爲false時，a.compareTo(b)會返回0。
在集合，如TreeMap，中還會發生其它問題：
// Foo class is "inconsistent with equals"assert foo1.equals(foo2) == false;assert foo1.compareTo(foo2) == 0; TreeMap<Foo, String> map = map.put(foo1, "a");map.put(foo2, "b");
當使用equals()方法時，這兩個對象不相等，但使用compareTo()時，它們卻相等。在這種情況下，該Map的元素個數將爲1，而非0。
由於這些"一致性相等"的問題，Javadoc說道"強烈建議(儘管並不要求)天然排序規則要與equals()方法保持一致"。
JDK中的許多類爲了符合"一致性相等"這一規範而實現了Comparable接口。這些類包括Byte，Short，Integer，Long，Character和String。
還有些更有趣的類：
BigDecimal--肯定是"非一致性相等"，比如4.00與4.0不一致，但進行比較時，認爲它們是一樣的。
Double/Float--該類顯式地提供了排序規則，併爲正零和負零，以及NaN都提供了相等性檢查，以確保它的compareTo()方法符合"一致性相等"。
CharSet--該類基於ID或名稱。equals()方法對待字段串是大小寫敏感的，但compareTo()方法卻不這樣。雖然名稱一般會符合某種標準，但這是一種值得懷疑的"一致性"。
*Buffer(nio)--該簇類的比較基於緩衝存放的內容，在我的測試中equals()和compareTo()是"一致的"。
Rdn(ldap)--該類的比較基於狀態的標準化格式，因此也是"一致性相等"。
ObjectStreamField(序列化)--該類的比較基於名稱，但會首先對基本數據類型進行排序。因爲沒有覆蓋equals()方法，所以是"非一致性相等"。
...
注意：對於大多數的例子，我都不得不查看其源代碼或編寫測試程序以確定該類是不是符合"一致性相等"。這兒有一個不錯地清理Javadoc和檢驗UUID equals()方法的Adopt-a-JDK任務。
JSR-310
一直看到許多關於BigDecimal的問題，已有計劃將JSR-310中的類改造成"一致性相等"，最近的一些帖子顯示這將造成多麼大的爭議。
基本上，爲某些類定義equals()和compareTo()看起來很容易。LocalDate表示某單一日曆系統中的某個日期，所以它有一個顯而易見的排序算法和相等規則。LocalTime則表示某個時刻，所以它也有一個明顯的排序算法和相等規則。Instant表示時間線上的某個時刻，那麼它的排序與相等也是顯見的。
但在其它的情況下，這就不是那麼顯而易見了。考慮這樣一個類OffsetDateTime：
dt1 = OffsetDateTime.parse("2012-11-05T06:00+01:00");
dt2 = OffsetDateTime.parse("2012-11-05T07:00+02:00");
這樣的兩個日期-時刻對象代表時間線上一個相同的時刻點，但它們有不同的本地時，而且相對的UTC/格林威治時間的偏移量也不相同。
那麼就有一個問題要留給讀者們...你更傾向於如下哪種觀點...
1. dt1不等於dt2，compareTo()分別比較本地時與偏移量，使用"一致性相等"(使用獨立的Comparator基於時刻對其進行排序)。
2. dt1不等於dt2，compareTo()基於時間線的上時刻點，使用"非一致性相等"。
3. dt1等於dt2，compareTo()基於時間線的上時刻點，使用"一致性相等"。
4. dt1等於dt2，且不實現Comparable接口。
5. dt1不等於dt2，且不實現Comparable接口。
我個人更傾向於讓dt1.equals(dt2)返回true這種方案，但我仍持開放態度。
順便地，也可以將這個問題提給BigDecimal，如果你能修改這個類，使其符合"一致性相等"，你會修改它的equals()方法，還是compareTo()方法？