解读equals方法与hashCode方法渊源_collection 中的equals 和hashcode那里来的-CSDN博客

一、equals() 所属以及内部原理（即Object中equals方法的实现原理）

说起equals方法，我们都知道是超类Object中的一个基本方法，用于检测一个对象是否与另外一个对象相等。而在Object类中这个方法实际上是判断两个对象是否具有相同的引用，如果有，它们就一定相等。其源码如下：

public boolean equals(Object obj) {   return (this == obj);     }

实际上我们知道所有的对象都拥有标识(内存地址)和状态(数据)，同时“==”比较两个对象的的内存地址，所以说 Object 的 equals() 方法是比较两个对象的内存地址是否相等，即若 object1.equals(object2) 为 true，则表示 equals1 和 equals2 实际上是引用同一个对象。

二、equals()与‘==’的区别

或许这是我们面试时更容易碰到的问题”equals方法与‘==’运算符有什么区别？“，并且常常我们都会胸有成竹地回答：“equals比较的是对象的内容，而‘==’比较的是对象的地址。”。但是从前面我们可以知道equals方法在Object中的实现也是间接使用了‘==’运算符进行比较的，所以从严格意义上来说，我们前面的回答并不完全正确。我们先来看一段代码并运行再来讨论这个问题。

package com.zejian.test;  
public class Car {  
    private int batch;  
    public Car(int batch) {  
        this.batch = batch;  
    }  
    public static void main(String[] args) {  
        Car c1 = new Car(1);  
        Car c2 = new Car(1);  
        System.out.println(c1.equals(c2));  
        System.out.println(c1 == c2);  
    }  
}

运行结果 false false

分析：对于‘==’运算符比较两个Car对象，返回了false，这点我们很容易明白，毕竟它们比较的是内存地址，而c1与c2是两个不同的对象，所以c1与c2的内存地址自然也不一样。现在的问题是，我们希望生产的两辆的批次（batch）相同的情况下就认为这两辆车相等，但是运行的结果是尽管c1与c2的批次相同，但equals的结果却反回了false。当然对于equals返回了false，我们也是心知肚明的，因为equal来自Object超类，访问修饰符为public，而我们并没有重写equal方法，故调用的必然是Object超类的原始方equals方法，根据前面分析我们也知道该原始equal方法内部实现使用的是’==’运算符，所以返回了false。因此为了达到我们的期望值，我们必须重写Car的equal方法，让其比较的是对象的批次（即对象的内容），而不是比较内存地址，于是修改如下：

@Override  
    public boolean equals(Object obj) {  
        if (obj instanceof Car) {  
            Car c = (Car) obj;  
            return batch == c.batch;  
        }  
        return false;  
    }

总结：默认情况下也就是从超类Object继承而来的equals方法与‘==’是完全等价的，比较的都是对象的内存地址，但我们可以重写equals方法，使其按照我们的需求的方式进行比较，如String类重写了equals方法，使其比较的是字符的序列，而不再是内存地址。

三、equals（）重写规则

前面我们已经知道如何去重写equals方法来实现我们自己的需求了，但是我们在重写equals方法时，还是需要注意如下几点规则的。

自反性。对于任何非null的引用值x，x.equals(x)应返回true。
对称性。对于任何非null的引用值x与y，当且仅当：y.equals(x)返回true时，x.equals(y)才返回true。
传递性。对于任何非null的引用值x、y与z，如果y.equals(x)返回true，y.equals(z)返回true，那么x.equals(z)也应返回true。
一致性。对于任何非null的引用值x与y，假设对象上equals比较中的信息没有被修改，则多次调用x.equals(y)始终返回true或者始终返回false。
对于任何非空引用值x，x.equal(null)应返回false。

关于equals的重写深入的研究可以参见链接：点这里这里不解释了，太多了~

四、为什么重写equals()的同时还得重写hashCode()

当然这个问题主要是针对映射相关的操作（Map接口）。学过数据结构的同学都知道Map接口的类会使用到键对象的哈希码，当我们调用put方法或者get方法对Map容器进行操作时，都是根据键对象的哈希码来计算存储位置的，因此如果我们对哈希码的获取没有相关保证，就可能会得不到预期的结果。在java中，我们可以使用hashCode()来获取对象的哈希码，其值就是对象的存储地址，这个方法在Object类中声明，因此所有的子类都含有该方法。那我们先来认识一下hashCode()这个方法吧。hashCode的意思就是散列码，也就是哈希码，是由对象导出的一个整型值，散列码是没有规律的，如果x与y是两个不同的对象，那么x.hashCode()与y.hashCode()基本是不会相同的，下面通过String类的hashCode()计算一组散列码：

package com.zejian.test;  
public class HashCodeTest {  
    public static void main(String[] args) {  
        int hash=0;  
        String s="ok";  
        StringBuilder sb =new StringBuilder(s);  
          
        System.out.println(s.hashCode()+"  "+sb.hashCode());  
          
        String t = new String("ok");  
        StringBuilder tb =new StringBuilder(s);  
        System.out.println(t.hashCode()+"  "+tb.hashCode());  
    }  
      
}

运行结果

3548  1829164700
3548  2018699554

我们可以看出，字符串s与t拥有相同的散列码，这是因为字符串的散列码是由内容导出的。而字符串缓冲sb与tb却有着不同的散列码，这是因为StringBuilder没有重写hashCode方法，它的散列码是由Object类默认的hashCode方法计算出来的对象存储地址，所以散列码自然也就不同了。那么我们该如何重写出一个较好的hashCode方法呢，其实并不难，我们只要合理地组织对象的散列码，就能够让不同的对象产生比较均匀的散列码。

重写equals方法时也必须重写hashCode方法。在Java API文档中关于hashCode方法有以下几点规定（原文来自java深入解析一书）。

在java应用程序执行期间，如果在equals方法比较中所用的信息没有被修改，那么在同一个对象上多次调用hashCode方法时必须一致地返回相同的整数。如果多次执行同一个应用时，不要求该整数必须相同。
如果两个对象通过调用equals方法是相等的，那么这两个对象调用hashCode方法必须返回相同的整数。
如果两个对象通过调用equals方法是不相等的，不要求这两个对象调用hashCode方法必须返回不同的整数。但是程序员应该意识到对不同的对象产生不同的hash值可以提供哈希表的性能。

通过前面的分析，我们知道在Object类中，hashCode方法是通过Object对象的地址计算出来的，因为Object对象只与自身相等，所以同一个对象的地址总是相等的，计算取得的哈希码也必然相等，对于不同的对象，由于地址不同，所获取的哈希码自然也不会相等。因此到这里我们就明白了，如果一个类重写了equals方法，但没有重写hashCode方法，将会直接违法了第2条规定，这样的话，如果我们通过映射表(Map接口)操作相关对象时，就无法达到我们预期想要的效果。

重写equals（）方法推荐使用getClass 而不是instanceof <当然也要视情况而定>

原文链接中的内容更加丰富，有兴趣的可以跳至原文。传送门