我们在重写equals的时候必须满足几个原则，否则，类在容器和其他场景下会出现奇怪的行为：
1.A.equals(A)=true,
2.对称性。即A.equals(B)=true;则B.equals(A)=true;这一点的反例为：我们想要与其他类实现互操作时。比如类A重写equals并且满足A.content.equal(s),其中content和s为字符串类型 ,那么类A就与String相同,但是反过来就不成立，并且当我们List<A> list;判断list.contains(s)时会发生奇怪的现象。
3.传递性。为了保证传递性我们不得不面对这个一个事实：我们无法保证扩展类的值组建的同时，又保留equals约定。比如超类重写了equals方法，子类在扩展的时候新加了值组件，这个时候超类等于子类，子类因为重写equals包含新值组件无法等于超类，为了满足对称性。在遇到超类时选择退化又会使的子类的2个对象都等于超类，但2个对象又因为新值组件的不同不能相等违反了传递性，jdk里Timestramp值组件扩展了Date，是既不推荐的做法，且Timestramp与Date不能混合使用。注意：当超类不可实例化的时候则没有上面的问题。
4.一致性，任何时候相等，任何时候不相等。反例：java.net.URL一个大错误
5.非空性：可以通过类型判断 省略if(o==null)的不必要判断
1.使用==操作符检查“参数是否为这个对象的引用”：性能优化且如果比较操作可能很昂贵，就值得这么做。
2.使用instanceof操作符检查"参数是否为正确的类型"：正确类型指equals方法所在的那个类，某些情况下是指该类所实现的某个接口。
3.把参数转化为正确的类型
4.对于该类中的每个“关键”域，检查参数中的域是否与该对象中的对应的域相匹配。float和double基本类型用Float.compare(float,float)比较
工具：
google的auto value和ide自动生成
原文：https://www.cnblogs.com/lccsblog/p/11129179.html