【Java】对于equals()和hashCode()的思考

在某些时候，我们需要判断两个对象是否相等。Java的每个类都继承于Object类。它使用equals()及hashCode()这两个方法来判断两个Object是否相等。 


1.  equals() 在API中的定义
需要满足5点： 
1 自省：对于任一非null引用x，x.equals(x)应返回true； 
2 反射：对于任一非null引用x及y，仅在y.equals(x)返回true时，x.equals(y)才返回true； 
3 传递：对于任一非null引用x、y及z，如果x.equals(y)为true，而且y.equals(z)为true，则x.equals(z)应返回true； 
4 稳定：对于任一非null引用x及y，如果用于比较的信息没有改变，无论多少次调用x.equals(y)都会恒定地返回true或false； 
5 对于任一非null引用x，x.equals(null)应返回false。 

Object的默认实现是只要在两个Object的引用相等时，才会返回true，即return x == y; 

如果要覆盖(override)此方法，需要同时覆盖hashCode()，要求是：两个相等的对象必须有相等的hash code。 

2. hashCode() 在API中的定义
其必须遵循的约定是： 
1 如果对象equals, 则hashCode一定相等; 
2 如果equals()返回false，这两个对象的hashCode()可能相同。但不等的两个对象返回不同的int值可以提高hashtables的运行效率。 

   作为常理，不相等的对象的hashCode()应可能地返回不同的int值。 

3. 对象是否相等的规则 

equals()相等的两个对象，hashcode()一定相等；

equals()不相等的两个对象，却并不能证明他们的hashcode()不相等。

反过来：

hashcode()不等，一定能推出equals()也不等；

hashcode()相等，equals()可能相等，也可能不等。

（先判断hashCode，再判断equals）

4. hashCode最大的用处是什么呢? 
Java中的集合（Collection）有两类，一类是List，再有一类是Set。 
你知道它们的区别吗？List集合内的元素是有序的，元素可以重复；Set集合内的元素无序，且元素不可重复。 
那么这里就有一个比较严重的问题了：要想保证元素不重复，可两个元素是否重复应该依据什么来判断呢？ 
这就是Object.equals方法了。但是，如果每增加一个元素就检查一次，那么当元素很多时，后添加到集合中的元素比较的次数就非常多了。 
Java采用了哈希表的原理, 哈希算法也称为散列算法，是将数据依特定算法直接指定到一个地址上. 初学者可以这样理解，hashCode方法实际上返回的就是对象存储的物理地址（实际可能并不是）。 
有了hashCode,当集合要添加新的元素时，先调用这个元素的hashCode方法，就一下子能定位到它应该放置的物理位置上。 
如果这个位置上没有元素，它就可以直接存储在这个位置上，不用再进行任何比较了；如果这个位置上已经有元素了， 
就调用它的equals方法与新元素进行比较，相同的话就不存了，不相同就散列其它的地址。 
所以这里存在一个冲突解决的问题。这样一来实际调用equals方法的次数就大大降低了，几乎只需要一两次. 

5. 为什么在HIBERNA里要重写hashCode和equals这两个方法? 
在hibernate中，经常使用set集合来保存相关对象，而set集合是不允许重复的, so, 道理同4.