一、不覆盖equals

==是物理相等

equals是逻辑相等

Object类的equals方法的实现：物理相等的话就逻辑相等。

不覆盖equals的情况下,类的每个实例都与它自身相等：

1、类的每个实例本质上都是唯一的

对于代表活动实体而不是值(value)的类来说确实如此，比如Thread

2、不关心类是否提供了"逻辑相等"的测试功能

3、超类已经覆盖了equals,从超类继承过来的行为对于子类也是合适的

例:Set实现类都继承了AbstractSet类的equals方法，List实现类都继承了AbstractList类的equals方法

4、类是私有的或是包级私有的,可以确定它的equals方法永远不会被调用 ？

这种情况下，只是对equals的一种废弃，并没有新加什么功能

二、覆盖equals：

类需逻辑相等时，而父类没覆盖equals实现期望行为：

比如要判断两个student是否是同一个人,这个时候我们就需要按需重写equals

自反性(reflexive) x.equals(x) true

对称性(symmetric) y.equals(x) true时,x.equals(y) true

传递性(transitive) x.equals(y)为true,y.equals(z) true, x.equals(z)true

一致性(consistent) 只要没修改，多次调用x.equals(y)就会一致地返回true,或者false

x.equals(null)必须返回false

有些类(如集合,HashMap)与equals方法息息相关,重写时小心

1、使用==操作符检查“参数是否为这个对象的引用”。性能优化

2、使用instanceof操作符检查“参数是否为正确的类型”。

3、把参数转换成正确的类型。

4、对于该类的每个“关键（significant）”域，检查参数中的域是否与该对象中对应的域相匹配。

else if (!name.equals(other.name)) 改成：

else if (name != other.name && !name.equals(other.name))

5、写完equals方法之后，问自己：是否的对称的、传递的、一致的。

1、覆盖equals时总要覆盖hashcode；

2、不要企图让equals方法过于智能；

只是想测试值是否相等

3、不要将equals声明中的Object对象替换为其他的类型

这样就变成了equals方法的重载，而不是重写。可以添加@Override注解来避免这种错误。

https://www.cnblogs.com/wangliyue/p/4448085.html

https://blog.csdn.net/w_linux/article/details/80041386