"一致性相等"的陷阱

关于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 language

if (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))

throw new Exception("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()方法？

原文链接：http://www.blogjava.net/jiangshachina/archive/2012/12/06/392569.html