Java hashcode()和equals()

最近，在公司做一个任务，需要重写hashcode()和equals()方法。但是为什么要重写这两个方法呢？
要弄清这个问题，我们首先得了解一下集合类。Java中的集（Collection）有两类，一类是List，再有一类是Set。它们的区别在于前者集合内的元素是有序的，元素可以重复；后者元素无序，但元素不可重复。

要想保证元素不重复，就得使用Object.equals方法了。但是，如果每增加一个元素就检查一次，当元素很多时，添加到集合中的元素比较的次数就非常多了。 这会大大降低程序的性能。

于是，Java设计者就利用哈希表的原理来解决这个问题。当要向集合中添加元素时，先调用这个元素的hashCode()方法，这个方法能迅速定位到它应该被放置的物理位置，如果这个位置上有元素，就调用该元素的equals()方法进行比较，相同的话就不存了，不同的话就再散列到其他位置去；如果该位置上没有元素，则不进行对equals()方法的调用，直接存放。流程图如下图所示。

通过这个算法，解决了多次调用equals()方法的问题；大大降低了调用equals()方法的次数。

我们可以这样来理解这个算法，先通过 hashcode来判断两个类是否存放某个桶里，但这个桶里可能有很多类，那么我们就需要再通过 equals 来在这个桶里找到我们要的类。
那么。重写了equals()，为什么还要重写hashCode()呢？
想想，你要在一个桶里找东西，你必须先要找到这个桶啊，你不通过重写hashcode()来找到桶，光重写equals()有什么用呢？

根据这个算法，我们不难得出，equals()相同的两个对象，hashCode()一定会相同；equals()不同的两个对象，hashCode()可能不同。这是散列算法造成的。这里不涉及散列算法的原理。可以这么理解，hashCode（）包含了equals（）。

由官方文档的定义，我们可以知道：
hashCode的存在主要是用于查找的快捷性，如Hashtable，HashMap等，hashCode是用来在散列存储结构中确定对象的存储地址的；这一点，从数据结构的知识中，也可以得到印证。
两个对象的hashCode相同，并不一定表示两个对象就相同，也就是不一定适用于equals(java.lang.Object) 方法，只能够说明这两个对象在散列存储结构中，如Hashtable，他们“存放在同一个篮子里”。
再归纳一下就是hashCode是用于查找使用的，而equals是用于比较两个对象的是否相等的。