为什么重写equals()方法

在Java中，我们不能重载==、+=、-+等操作符的行为。他们的行为是特定的。让我们关注一下这里的运算符==。

operator ==如何工作。

它检查我们比较的两个引用是否指向内存中的同一个实例。只有当这两个引用表示内存中的同一个实例时，Operator ==才会解析为true。

现在让我们考虑下面的例子

public class Person {

      private Integer age;
      private String name;
    
      ..getters, setters, constructors
      }

假设在你的程序中，你在不同的地方建立了2个Person对象，你希望比较它们。

Person person1 = new Person("Mike", 34);
Person person2 = new Person("Mike", 34);
System.out.println ( person1 == person2 );  --> will print false!

这两个对象从商业角度看是一样的，对吧?对于JVM，它们是不一样的。因为它们都是用new关键字创建的，所以这些实例位于内存中的不同段中。因此运算符==将返回false

但是如果我们不能重写==操作符，我们怎么能对JVM说我们希望这两个对象被视为相同的。这里出现了.equals()方法。

您可以重写equals()来检查某些对象是否具有相同的值，以便将特定字段视为相等。

您可以选择要比较的字段。如果我们说2个Person对象当且仅当它们具有相同的年龄和相同的名称时是相同的，那么IDE将为自动生成equals()创建如下内容

@Override
    public boolean equals(Object o) {
        if (this == o) return true;
        if (o == null || getClass() != o.getClass()) return false;
        Person person = (Person) o;
        return age == person.age &&
                name.equals(person.name);
    }

让我们回到前面的例子

    Person person1 = new Person("Mike", 34);
    Person person2 = new Person("Mike", 34);
    System.out.println ( person1 == person2 );   --> will print false!
    System.out.println ( person1.equals(person2) );  --> will print true!

所以我们不能重载==运算符来以我们想要的方式比较对象，但是Java给了我们另一种方法，equals()方法，我们可以随心所欲地重写它。

但是请记住，如果我们没有在我们的类中提供.equals()的自定义版本(也就是重写)，那么Object类和==操作符中预定义的.equals()将表现完全相同。

从Object继承的默认equals()方法将检查两个比较实例在内存中是否相同!

为什么重写hashCode()方法

java中的一些数据结构(如HashSet, HashMap)基于应用于这些元素上的哈希函数来存储它们的元素。哈希函数是hashCode()

如果我们可以选择重写.equals()方法，那么我们也必须选择重写hashCode()方法。这是有原因的。

继承自Object的hashCode()的默认实现认为内存中的所有对象都是唯一的!

让我们回到哈希数据结构。对于这些数据结构有一个规则。

HashSet不能包含重复的值，HashMap不能包含重复的键

HashSet是在幕后使用HashMap实现的，HashSet的每个值都存储为HashMap中的一个键。

所以我们必须理解HashMap是如何工作的。

简单地说，HashMap是一个具有一些桶的原生数组。每个桶都有一个linkedList。在那个linkedList中存储了我们的键。HashMap通过应用hashCode()方法为每个键定位正确的linkedList，然后它遍历该linkedList中的所有元素，并对每个元素应用equals()方法，以检查该元素是否已经包含在其中。不允许重复密钥。

当我们在HashMap中放东西时，键就存储在其中一个linkedlist中。该键将存储在哪个linkedList中，由该键上的hashCode()方法的结果显示。因此，如果key1. hashcode()的结果是4，那么key1将存储在数组的第4个桶中，在那里存在的linkedList中。

默认情况下，hashCode()方法为每个不同的实例返回不同的结果。如果我们有默认的equals()，它的行为类似于==，它将内存中的所有实例视为不同的对象，我们就没有任何问题。

但在前面的示例中，我们说过，如果Person实例的年龄和名字匹配，则认为Person实例是相等的。

    Person person1 = new Person("Mike", 34);
    Person person2 = new Person("Mike", 34);
    System.out.println ( person1.equals(person2) );  --> will print true!

现在让我们创建一个映射，将这些实例存储为键，并使用一些字符串作为pair值

Map<Person, String> map = new HashMap();
map.put(person1, "1");
map.put(person2, "2");

在Person类中，我们没有重写hashCode方法，但我们重写了equals方法。由于默认的hashCode为不同的java实例提供不同的结果，person1.hashCode()和person2.hashCode()很有可能得到不同的结果。

我们的映射可能以这些人在不同的链表中结束。

这违背了HashMap的逻辑

一个HashMap不允许有多个相等的键!

但是我们现在有了，原因是从对象类继承的默认hashCode()是不够的。在Person类上重写equals()方法之后就不会了。

这就是为什么我们必须在重写equals方法之后重写hashCode()方法的原因。

现在我们来解决这个问题。让我们重写hashCode()方法来考虑equals()考虑的相同字段，即年龄、姓名

 public class Person {

      private Integer age;
      private String name;
    
      ..getters, setters, constructors

    @Override
    public boolean equals(Object o) {
        if (this == o) return true;
        if (o == null || getClass() != o.getClass()) return false;
        Person person = (Person) o;
        return age == person.age &&
                name.equals(person.name);
    }

    @Override
    public int hashCode() {
        return Objects.hash(name, age);
    }

      }

现在让我们再次尝试将这些键保存到HashMap中

Map<Person, String> map = new HashMap();
map.put(person1, "1");
map.put(person2, "2");

person1.hashCode()和person2.hashCode()肯定是相同的。假设它是0。

HashMap将进入0桶，在LinkedList中将person1保存为值为“1”的键。对于第二次放置HashMap是足够智能的，当它再次到bucket 0保存值为“2”的person2 key时，它将看到另一个相等的key已经存在于那里。它会覆盖之前的键。最后HashMap中只有person2键。

现在我们与哈希映射规则保持一致，该规则说不允许有多个相等的键!

Bah -“你必须在每个重写equals()的类中重写hashCode()。”

[出自Joshua Bloch的《Effective Java》?］

Isn't this the wrong way round? Overriding hashCode likely implies you're writing a hash-key class, but overriding equals certainly does not. There are many classes that are not used as hash-keys, but do want a logical-equality-testing method for some other reason. If you choose "equals" for it, you may then be mandated to write a hashCode implementation by overzealous application of this rule. All that achieves is adding untested code in the codebase, an evil waiting to trip someone up in the future. Also writing code you don't need is anti-agile. It's just wrong (and an ide generated one will probably be incompatible with your hand-crafted equals).

他们肯定应该在被写来用作键的对象上强制设置一个接口吗?无论如何，Object永远不应该提供默认的hashCode()和equals() imho。它可能鼓励了许多破碎的散列集合。

但无论如何，我认为“规则”是前后颠倒的。与此同时，我将继续避免使用“等号”进行相等性测试方法:-(

The methods equals and hashcode are defined in the object class. By default if the equals method returns true, then the system will go further and check the value of the hash code. If the hash code of the 2 objects is also same only then the objects will be considered as same. So if you override only equals method, then even though the overridden equals method indicates 2 objects to be equal , the system defined hashcode may not indicate that the 2 objects are equal. So we need to override hash code as well.

简单地说，Object中的equals-方法检查引用是否相等，当属性相等时，类的两个实例在语义上仍然相等。例如，当将对象放入使用等号和hashcode(如HashMap和Set)的容器中时，这很重要。假设我们有这样一个类:

public class Foo {
    String id;
    String whatevs;

    Foo(String id, String whatevs) {
        this.id = id;
        this.whatevs = whatevs;
    }
}

我们创建了两个具有相同id的实例:

Foo a = new Foo("id", "something");
Foo b = new Foo("id", "something else");

如果不重写等号，我们将得到:

A.equals (b)为假，因为它们是两个不同的实例 a.equals(a)为真，因为它是同一个实例 b.equals(b)为真，因为它是同一个实例

正确吗?也许吧，如果这是你想要的。但假设我们希望具有相同id的对象是相同的对象，不管它是否是两个不同的实例。我们重写等号(和hashcode):

public class Foo {
    String id;
    String whatevs;

    Foo(String id, String whatevs) {
        this.id = id;
        this.whatevs = whatevs;
    }

    @Override
    public boolean equals(Object other) {
        if (other instanceof Foo) {
            return ((Foo)other).id.equals(this.id);   
        }
    }

    @Override
    public int hashCode() {
        return this.id.hashCode();
    }
}

至于实现equals和hashcode，我建议使用Guava的helper方法

Java提出了一个规则

如果使用Object类的equals方法，两个对象相等，那么hashcode方法应该为这两个对象提供相同的值。

因此，如果在我们的类中重写equals()，我们也应该重写hashcode()方法来遵循此规则。 例如，equals()和hashcode()这两个方法都用于Hashtable中以键值对的形式存储值。如果我们覆盖其中一个而不是另一个，如果我们使用这样的对象作为键，哈希表可能不会像我们想要的那样工作。

常见错误如下例所示。

public class Car {

    private String color;

    public Car(String color) {
        this.color = color;
    }

    public boolean equals(Object obj) {
        if(obj==null) return false;
        if (!(obj instanceof Car))
            return false;   
        if (obj == this)
            return true;
        return this.color.equals(((Car) obj).color);
    }

    public static void main(String[] args) {
        Car a1 = new Car("green");
        Car a2 = new Car("red");

        //hashMap stores Car type and its quantity
        HashMap<Car, Integer> m = new HashMap<Car, Integer>();
        m.put(a1, 10);
        m.put(a2, 20);
        System.out.println(m.get(new Car("green")));
    }
}

绿色的车没有找到

2. hashCode()引起的问题

该问题是由未覆盖的hashCode()方法引起的。equals()和hashCode()之间的契约是:

如果两个对象相等，那么它们必须具有相同的哈希码。 如果两个对象具有相同的哈希码，则它们可能相等，也可能不相等。 公共int hashCode(){ 返回this.color.hashCode (); ｝