Question

我一直在尝试以下equals＆amp; amp;的hashCode：

@Override
public boolean equals(Object obj) {
    return obj != null && hashCode() == obj.hashCode();
}

@Override
public int hashCode() {
    return new HashCodeBuilder().append(myField1).append(myField2).toHashCode();
}

基本上，我希望equals为具有相同true的任何2个类返回hashCode，这将归结为我用于生成hashCode的字段的值。

我知道这也会为不同的类返回true，这些类恰好在这些字段中具有相同的值。

问题：这种实施的缺陷是什么？

Answer 1

哈希碰撞。具有不同字段值的实例可能具有匹配的哈希码，因此比较相等。我不确定为什么这会有用。

Answer 2

正如Oli所说，你将确保具有相同数据的2个对象匹配，但是具有相同hashCode的非匹配对象将会这样做，请记住使用哈希码对哈希表中的元素进行排序以优化排序而不是用于比较，为确保等于方法，您应该比较对象的精细数据，如：

public boolean equals(Object obj) {
    if (obj instanceof THISOBJECT) {
        THISOBJECT other = (THISOBJECT) obj;
        return getID.equals(other.getID);
    }
    return false;
}

Answer 3

如果测试两个对象的相等性是很昂贵的，并且如果对象的哈希码是已知的，那么测试哈希码作为第一步来测试相等性可能会有所帮助。如果哈希码不相等，则无需进一步查看。如果他们是平等的，那么更详细地检查一下。例如，假设一个人有许多100,000个字符的字符串，恰好在最后十个字符中有所不同（但没有理由认为是这种情况）。即使与哈希码有1％的错误匹配率，在详细检查字符串内容之前检查哈希码可以提供近100倍的加速，而不是反复检查每个字符串的前9,990个字符。

哈希码的目标通常不是唯一的，而是为了降低涉及虚假哈希匹配的比较成本与哈希码计算的成本在同一个球场。如果给定的哈希码生成如此多的错误匹配，那么处理那些花费的时间占据了计算哈希码的时间，那么如果它可以减少错误匹配的数量，则花费更多时间来计算哈希码可能是值得的。如果散列算法如此有效以至于计算散列码所花费的时间占据了错误匹配所花费的时间，那么使用更快的散列算法可能会更好，即使错误匹配的数量会增加。

使用hashCode实现等于没有去？

3 个答案: