比较与equals一致意味着什么？如果我的班级不遵循这个原则，可能会发生什么？

问题描述 投票：16回答：4

从TreeMap的JavaDoc：

请注意，如果此有序映射要正确实现Map接口，则由有序映射维护的排序（无论是否提供显式比较器）必须与equals一致。 （请参阅Comparable或Comparator以获得与equals一致的精确定义。）这是因为Map接口是根据equals操作定义的，但是map使用compareTo（或compare）方法执行所有键比较，因此有两个键从排序地图的角度来看，通过这种方法被视为相等的是相等的。即使排序与equals不一致，也可以很好地定义有序映射的行为。它只是不遵守Map接口的一般合同。

有人可以给出一个具体的例子来说明如果排序与equals不一致可能会出现的问题吗？例如，用户定义的类具有自然顺序，即它实现了Comparable。 JDK中的所有内部类都保持这个不变量吗？

java comparison equals comparator comparable
4个回答
12
投票

contract of the Comparable interface允许不一致的行为：

强烈建议（尽管不要求）自然排序与equals一致。

所以从理论上讲，JDK中的一个类可能有一个与compareTo不一致的equals。一个很好的例子是BigDecimal。

下面是一个与equals不一致的比较器的设计示例（它基本上表示所有字符串都相等）。

输出：

大小：1 内容：{a = b}

public static void main(String[] args) {
    Map<String, String> brokenMap = new TreeMap<String, String> (new Comparator<String>() {

        @Override
        public int compare(String o1, String o2) {
            return 0;
        }
    });

    brokenMap.put("a", "a");
    brokenMap.put("b", "b");
    System.out.println("size: " + brokenMap.size());
    System.out.println("content: " + brokenMap);
}
19
投票

假设我们有这个简单的Student类实现Comparable<Student>但不会覆盖equals() / hashCode()。当然equals()与compareTo()不一致 - 两个不同的学生使用相同的age不相等：

class Student implements Comparable<Student> {

    private final int age;

    Student(int age) {
        this.age = age;
    }

    @Override
    public int compareTo(Student o) {
        return this.age - o.age;
    }

    @Override
    public String toString() {
        return "Student(" + age + ")";
    }
}

我们可以安全地在TreeMap<Student, String>中使用它：

Map<Student, String> students = new TreeMap<Student, String>();
students.put(new Student(25), "twenty five");
students.put(new Student(22), "twenty two");
students.put(new Student(26), "twenty six");
for (Map.Entry<Student, String> entry : students.entrySet()) {
    System.out.println(entry);
}
System.out.println(students.get(new Student(22)));

结果很容易预测：学生根据他们的年龄（尽管按不同的顺序插入）很好地排序，并使用new Student(22)关键作品获取学生并返回"twenty two"。这意味着我们可以安全地在Student中使用TreeMap类。

然而将students改为HashMap并且事情变得糟糕：

Map<Student, String> students = new HashMap<Student, String>();

显然，由于散列，项目的枚举返回“随机”顺序 - 这很好，它不违反任何Map合同。但最后一句话完全被打破了。因为HashMap使用equals() / hashCode()来比较实例，所以通过new Student(22)键获取值失败并返回null！

这就是JavaDoc试图解释的内容：这些类可以与TreeMap一起使用，但可能无法与其他Map实现一起使用。请注意，Map操作是根据equals() / hashCode()记录和定义的，例如： containsKey()：

当且仅当此地图包含密钥k的映射（例如(key==null ? k==null : key.equals(k))）时，[...]才返回true

因此，我不相信有任何标准的JDK类实现Comparable但未能实现equals() / hashCode()对。

19
投票

这是一个简单但实​​际的例子，说明如果比较方法与equals不一致会发生什么。在JDK中，BigDecimal实现了Comparable，但它的比较方法与equals不一致。例如：

> BigDecimal z = new BigDecimal("0.0")
> BigDecimal zz = new BigDecimal("0.00")
> z.compareTo(zz)
0
> z.equals(zz)
false

这是因为BigDecimal的比较方法只考虑数值，但equals也考虑了精度。由于0.0和0.00具有不同的精度，即使它们具有相同的数值，它们也是不相等的。

这是一个例子，说明TreeSet违反Set的总合同意味着什么。 （这与TreeMap和Map的情况相同，但使用集合进行演示更容易。）让我们将contains的结果与将元素从集合中调出并调用equals的结果进行比较：

> TreeSet<BigDecimal> ts = new TreeSet<>()
> ts.add(z)
> ts.contains(z)
true
> z.equals(ts.iterator().next())
true
> ts.contains(zz)
true
> zz.equals(ts.iterator().next())
false

令人惊讶的是，TreeSet说它包含对象zz，但它与实际包含在集合中的元素不相等。原因是TreeSet使用其比较方法（BigDecimal.compareTo）来确定集合成员资格，而不是equals。

现在让我们将TreeSet与HashSet进行比较：

> HashSet<BigDecimal> hs = new HashSet<>(ts)
> hs.equals(ts)
true
> ts.contains(zz)
true
> hs.contains(zz)
false

这很奇怪。我们有两个相同的集合，但是一个集合表示它包含一个对象，但另一个集合表示它不包含相同的对象。同样，这反映了TreeSet正在使用比较方法的事实，而HashSet正在使用equals。

现在让我们将另一个对象添加到HashSet，看看会发生什么：

> HashSet<BigDecimal> hs2 = new HashSet<>()
> hs2.add(zz)
> ts.equals(hs2)
true
> hs2.equals(ts)
false

现在这很奇怪。一组说它等于另一组，但另一组说它不等于第一组！要理解这一点，您需要了解如何确定集合的相等性。如果a）它们具有相同的大小，则认为两组相等，并且b）另一组中的每个元素也包含在该组中。也就是说，如果你有

set1.equals(set2)

然后，相等算法查看大小，然后迭代set2，并为每个元素检查该元素是否包含在set1中。这就是不对称性的来源。当我们这样做时

ts.equals(hs2)

两个集合的大小都是1，因此我们继续进行迭代步骤。我们迭代hs2并使用然后调用TreeSet.contains方法 - 它使用比较方法。就TreeSet而言，它等于HashSet hs2。

现在我们做的时候

hs2.equals(ts)

比较是另一回事。我们迭代TreeSet并得到它的元素，并问hs2它是否contains那个元素。由于HashSet.contains使用equals，因此返回false，整体结果为false。

7
投票

这是另一个与equals和AND排序的一致性实现重要的例子。

假设我们有一个对象MyObject，它有两个字段：id和quantity。 id顾名思义是对象的自然键，而quantity只是一个属性。

public class MyObject {
  int id;
  int quantity;
  ...
}

让我们想象一下，我们想要使用按MyObject降序排序的quantity集合。我们可以写的第一个比较器是：

Comparator<MyObject> naiveComp = new Comparator<MyObject>() {
  @Override
  public int compare(MyObject o1, MyObject o2) {
    return o2.quantity - o1.quantity;
  }
};

在TreeMap / TreeSet中使用配备此比较器的MyObject实例会失败，因为它的比较器与equals不一致（请参阅下面的完整代码）。让它与equals保持一致：

Comparator<MyObject> slightlyBetterComp = new Comparator<MyObject>() {
  @Override
  public int compare(MyObject o1, MyObject o2) {
    if (o1.equals(o2)) {
      return 0;
    }
    if (o1.quantity == o2.quantity) {
      return -1; // never 0
    }
    return o2.quantity - o1.quantity; // never 0
  }
};

但是，这再次失败以适应TreeSet / TreeMap！ （参见下面的完整代码）这是因为排序关系不是完全的，即不能将任何两个对象严格地置于排序关系中。在这个比较器中，当quantity字段相等时，得到的排序是不确定的。

一个更好的比较器是：

Comparator<MyObject> betterComp = new Comparator<MyObject>() {
  @Override
  public int compare(MyObject o1, MyObject o2) {
    if (o1.equals(o2)) {
      return 0;
    }
    if (o1.quantity == o2.quantity) {
      return o1.id - o2.id; // never 0
    }
    return o2.quantity - o1.quantity; // never 0
  }
};

该比较器确保：

  • 当compareTo返回0时，它意味着两个对象是equal（初始检查相等）
  • 当id相等时，使用quantity作为判别排序字段完全排序所有项目

完整测试代码：

package treemap;

import java.util.Comparator;
import java.util.HashMap;
import java.util.Map;
import java.util.TreeMap;

public class MyObject {
  int id;
  int quantity;

  public MyObject(int id, int quantity) {
    this.id = id;
    this.quantity = quantity;
  }

  @Override
  public int hashCode() {
    int hash = 7;
    hash = 97 * hash + this.id;
    return hash;
  }

  @Override
  public boolean equals(Object obj) {
    if (obj == null) {
      return false;
    }
    if (getClass() != obj.getClass()) {
      return false;
    }
    final MyObject other = (MyObject) obj;
    if (this.id != other.id) {
      return false;
    }
    return true;
  }

  @Override
  public String toString() {
    return "{" + id + ", " + quantity + "}";
  }

  public static void main(String[] args) {
    String format = "%30.30s: %s\n";
    Map<MyObject, Object> map = new HashMap();
    map.put(new MyObject(1, 100), 0);
    map.put(new MyObject(2, 100), 0);
    map.put(new MyObject(3, 200), 0);
    map.put(new MyObject(4, 100), 0);
    map.put(new MyObject(5, 500), 0);
    System.out.printf(format, "Random Order", map.keySet());

    // Naive non-consisten-with-equal and non-total comparator
    Comparator<MyObject> naiveComp = new Comparator<MyObject>() {
      @Override
      public int compare(MyObject o1, MyObject o2) {
        return o2.quantity - o1.quantity;
      }
    };
    Map<MyObject, Object> badMap = new TreeMap(naiveComp);
    badMap.putAll(map);
    System.out.printf(format, "Non Consistent and Non Total", badMap.keySet());

    // Better consisten-with-equal but non-total comparator
    Comparator<MyObject> slightlyBetterComp = new Comparator<MyObject>() {
      @Override
      public int compare(MyObject o1, MyObject o2) {
        if (o1.equals(o2)) {
          return 0;
        }
        if (o1.quantity == o2.quantity) {
          return -1; // never 0
        }
        return o2.quantity - o1.quantity; // never 0
      }
    };
    Map<MyObject, Object> slightlyBetterMap = new TreeMap(naiveComp);
    slightlyBetterMap.putAll(map);
    System.out.printf(format, "Non Consistent but Total", slightlyBetterMap.keySet());

    // Consistent with equal AND total comparator
    Comparator<MyObject> betterComp = new Comparator<MyObject>() {
      @Override
      public int compare(MyObject o1, MyObject o2) {
        if (o1.equals(o2)) {
          return 0;
        }
        if (o1.quantity == o2.quantity) {
          return o1.id - o2.id; // never 0
        }
        return o2.quantity - o1.quantity; // never 0
      }
    };
    Map<MyObject, Object> betterMap = new TreeMap(betterComp);
    betterMap.putAll(map);
    System.out.printf(format, "Consistent and Total", betterMap.keySet());
  }
}

输出：

                  Random Order: [{5, 500}, {4, 100}, {3, 200}, {2, 100}, {1, 100}]
  Non Consistent and Non Total: [{5, 500}, {3, 200}, {4, 100}]
      Consistent but Not Total: [{5, 500}, {3, 200}, {4, 100}]
          Consistent and Total: [{5, 500}, {3, 200}, {1, 100}, {2, 100}, {4, 100}]

结论：

虽然我认为从概念上将身份与排序隔离是非常合理的。例如，在关系数据库术语中：

select * from MyObjects order by quantity

工作得很好。我们不关心这里的对象身份，也不想要总排序

但是，由于基于树的集合实现中的约束，必须确保他们编写的任何比较器：

  • 与equals的一致性
  • 提供所有可能对象的总排序
最新问题
© www.soinside.com 2019 - 2024. All rights reserved.