为什么HashCode相同的两个对象可能不相等？

面试中曾经有这么一道题目，考察的是开发者对于 equals()和 hashCode()的理解， 题目是这样的，

有对象A和B， A.equals(B) == true, A和B的 hashCode可以不同。

答案是否定的。如果A和B equals的话，那么他们的哈希值一定要相同。 理解这个问题，首先要明白 equals和 hashCode扮演的是什么角色。

equals的原则

在Java中对 equals有这么几个原则， · 自反性: A.equals(A) == true · 对称性: if(A.equals(B)), then B.equals(A) == true · 一致性: 在A B没有被修改的前提下，多次 A.equals(B)的结果应该一致 · 传递性: A.eqausl(B) == true, B.eqauls(C) == true, then A.equals(C) == true

hashCode的计算

举个例子，在没有 hashCode的情况下，在 Set集合中存储1000个对象的话需要用 equals来比较对象的值是否重复， 我们知道 Set是不允许重复对象存在的， 那么当这一千个对象都不重复的情况下， 第1000个对象的存储需要调用1000次 equals去进行比较，这是非常低效的。

而hashCode能解决这种问题，对象的存储不再是顺序存放，而是通过 hashCode直接计算出存储的位置， (可以理解为内存地址，虽然并不是) 之后新对象在存储的时候如果 hashCode跟之前的没有重复则直接存储，如果重复了则用 equals()校验是否相等， 如果不相等的话，以 HashMap作为例子，默认是在同一个地址上用链表存储起来新的对象， 这在之前介绍哈希冲突的解决办法那篇文章里提到过。

equals和 hashCode的总结

在理解了上面 equals的原则和 hashCode的原则之后我们可以推导出这么个结论， · 如果两个对象 equals，那么他们的 hashCode一定要相同(否则在Set中就会出现重复元素) · 如果两个对象 hashCode相同，他们可以不 equals 所以如果不好记住这俩的关系的话，可以试着从数据集合的存储这个角度出发来理解eqauls和 hashCode哦。