为什么重写equals必须重写hashCode
1. Object中equals、hashCode
public native int hashCode();
public boolean equals(Object obj) {
return (this == obj);
}
首先看一下equals方法，Object中默认比较两个对象的地址。也就是说如果一个类默认的equals，就比较地址。而反观hashCode方法，我们先来看一下hashCode注释
再结合Effective Java 第三版中所提到的
每个覆盖了equals方法的类中，必须覆盖hashCode。如果不这么做，就违背了hashCode的通用约定，也就是上面注释中所说的。进而导致该类无法结合所以与散列的集合一起正常运作，这里指的是HashMap、HashSet、HashTable、ConcurrentHashMap。
2. equals和hashCode同时存在的意义
equals和hashCode都是用来判断两个对象想不想等的，那么问题来了？
为什么需要两个呢？
- equals - 保证比较对象是否是绝对相等的
- hashCode - 保证在最快的时间内判断两个对象是否相等，可能有误差值
一个是保证可靠，一个是保证性能。也就是说：
- 同一个对象的hashCode一定相等，不同对象的hashCode也可能相等，这是因为hashCode是根据地址hash出来的一个int 32 位的整型数字，相等是在所难免。
- equals比较的是两个对象的地址，同一个对象地址肯定相同，不同的对象地址一定不同，可靠性是这么来的。
就像HashMap里面插入时判断：
if (p.hash == hash &&
((k = p.key) == key || (key != null && key.equals(k))))
判断两个key是否相同逻辑
- 先比较 hash (通过hashCode的高16位和低16位进行异或运算得出的) ，因为两个相同的对象hash值一定相等。
- 再比较两个对象的地址是否相同，== 判断是否绝对相等，而equals判断是否客观相等。
下面分析一下简单的不重写hashCode的后果和在存到HashMap中可能出现的后果
3. 如果只重写equals的后果
- 无论是
Effective Java，还是阿里巴巴Java规范手册都是要求重写equals，必须重写hashCode。 - 两个相等的对象必须具有相等的散列码（Java关键约定）
那么不重写的后果是什么呢？
举一个例子：
如果一个只重写了equals(比较所有属性是否相等)的类 new 出了两个属性相同的对象。这时可以得到的信息是这个属性相同的对象地址肯定不同，但是equals是true，hashCode返回的是不相等的(一般不会出现hash碰撞)。
也就是说这个类对象违背了Java对于两个对象相等的约定。违背约定的原因是 可靠的equals判断两个对象是相等的，但是他们两个的散列码确是不相等的。
总结来说：
- equals 为 true ， hashCode 必须相等
- hashCode 相等时 ， equals 可以不用为 true （也就是hash碰撞的时候）
4 . 不重写HashCode对于散列表的影响
if (p.hash == hash &&
((k = p.key) == key || (key != null && key.equals(k))))
相同的场景，相同配方：
两个所有属性都相等的对象，但是地址不同。没重写
hashCode时，p.hash == hash一定不相等。但是逻辑上这两个对象是相等的，并且equals也是相等的。 这就会导致，HashMap里面本来有这个key，但是你告诉我没有，导致了put操作成功。逻辑上是不符合规范的，get时取出来的也可能是自己另一个的value。
