Object类中有这样一段说明，意思是建议我们equals方法和hashCode方法，或者一起重写，或者一起不重写，以维护hashCode的常规协定。
什么叫hashCode的常规协定呢？
我的理解就是：两个对象通过equals方法进行比较相等，它们分别调用hashCode方法时一定返回相同的整数；两个对象通过equals方法比较不相等是，不要求它们调用hashCode方法时必须返回不同的值，但是程序员应该意识到，在这种情况下，让它们返回不同的可以提高哈希表的性能。
怎么又涉及到哈希表的性能呢？
其实，我们一般不会直接调用hashCode方法，但是在集合中它们会被频繁的使用。重写equals方法时建议重写hashCode方法，是针对像Map、Set这种集合操作而言的。
我们创建一个类，谁都不能保证它什么时候会被放到集合中，所以，为了避免不必要的麻烦，建议重写equals方法的同时也重写hashCode方法，重写hashCode方法的同时也一起重写equals方法。
其实，equals方法与hashCode方法不一致会带来两个比较明显的问题。
一、理解困难，容易混淆
二、查找效率低下，也就是所谓的哈希表的性能会降低
这又从何说起呢？
我们知道，HashMap底层维护的是一个Entry类型的数组，向HashMap中添加键值对时，首先通过Key值计算出一个位置，该位置可能就是此元素将要放置的位置。如果发现，这个位置上没有元素，也就是为null，那么就直接将这个待添加的元素放置在该位置上。如果这个位置上已经有元素存在，那么接着通过equals方法比较这个待添加的元素Key与已经存在的这个元素的Key是否相等，不相等则执行添加操作，相等则返回旧值不执行添加操作。注意，这种情况下执行添加操作是将待添加的元素放置这个位置上，然后让这个待添加的元素指向已经存在的这个旧元素，如此在这个位置上就形成了链表。同理，取出元素是和添加类似，是通过给定对象的hashCode()方法计算出一个位置，然后在该位置上进行查找，找到就返回该元素，否则返回null。
明白了这个过程就好办了。
如果equals方法与hashCode方法一致，那么在HashMap所维护的那个Entry类型的数组中的每个位置上就只有一个元素，而不会形成链表，这样一来查找的性能就非常好，同时理解上也十分清晰明了。反之，如果二者不一致，就有可能造成难以理解或者查找的性能比较低。
下面以String类举例说明：
-
假设String类只重写了equals()方法，而没有重写hashCode()方法。也就是说其hashCode()方法仍然继承Object类的hashCode()方法。
看下面的代码段
HashSet set = new HashSet();
String s1 = new String("hello");
String s2 = new String("hello");
set.add(s1);
set.add(s2);
System.out.println(set.size()); //输出为2
此时，set中有两个元素，这两个元素的内容都为"hello",它们存储在数组中的不同位置上，因为
两个对象的hashCode()返回值不同。
如果我们将set中的元素迭代出来，就会看到两个"hello"。这就造成了理解上困难了，因为在我
们的记忆中set中的元素是不能重复的，但现在这个HashSet对象中却有两个"hello",这怎么解释
呢？虽然，它们实际上是两个不同的对象，但从表象上看它们确实是“一样的”，也只有构造这 个HashSet对象的我们知道，但是其它调用者却很难理解，这就是所谓的理解上的混乱。
-
假如String类只重写了hashCode()方法，而没有重写hashCode()方法。
同样，我们看上面那段代码
set中仍然有两个元素，但是相对于HashMap底层的那个Entry数组来说，这两个元素在相同的位置上，并且形成了链表，s2指向s1，因为s1和s2的hashCode()返回值相同，但通过equals()方法进行比较却返回false。
这样一来，查找起来就比较费劲了，因为要遍历链表。
我们知道，链表遍历只能是通过前一个元素找下一个元素。
我们这里是两个对象，找起来可能不那么费力，但是对象多了呢？链表长了呢？
这就是所谓的效率低。
这两点就造成了我们前面提到的哈希表的性能的下降。
综上所诉，虽然不强制要求重新equals方法时必须重写hashCode方法或者是重写hashCode方法必须重写equals方法，但是为了避免不必要的麻烦，建议二者要么一起重写，要么都不重写，以保持它们的一致性。
以上是作者的一点点理解，如有纰漏之处，还请多多指教。
本文转自 手不要乱摸 51CTO博客，原文链接:http://blog.51cto.com/5880861/1335139