我在arrays . deephashcode(…)周围使用了一个小包装器，因为它可以正确地处理作为参数提供的数组

public static int hash(final Object... objects) {
    return Arrays.deepHashCode(objects);
}

最好使用Eclipse提供的功能，它做得非常好，您可以把精力和精力放在开发业务逻辑上。

任何在可能的范围内均匀分布哈希值的哈希方法都是一个很好的实现。参见effective java (http://books.google.com.au/books?id=ZZOiqZQIbRMC&dq=effective+java&pg=PP1&ots=UZMZ2siN25&sig=kR0n73DHJOn-D77qGj0wOxAxiZw&hl=en&sa=X&oi=book_result&resnum=1&ct=result)，其中有一个关于hashcode实现的好技巧(第9项我认为…)

关于8.blogspot.com，你说过

如果equals()对于两个对象返回true，那么hashCode()应该返回相同的值。如果equals()返回false，那么hashCode()应该返回不同的值

我不同意你的看法。如果两个对象具有相同的hashcode，并不意味着它们是相等的。

如果A等于B，那么A.hashcode必须等于B.hascode

but

如果A.hashcode等于B.hascode，这并不意味着A必须等于B

对于简单类，通常最容易基于equals()实现检查的类字段实现hashCode()。

public class Zam {
    private String foo;
    private String bar;
    private String somethingElse;

    public boolean equals(Object obj) {
        if (this == obj) {
            return true;
        }

        if (obj == null) {
            return false;
        }

        if (getClass() != obj.getClass()) {
            return false;
        }

        Zam otherObj = (Zam)obj;

        if ((getFoo() == null && otherObj.getFoo() == null) || (getFoo() != null && getFoo().equals(otherObj.getFoo()))) {
            if ((getBar() == null && otherObj. getBar() == null) || (getBar() != null && getBar().equals(otherObj. getBar()))) {
                return true;
            }
        }

        return false;
    }

    public int hashCode() {
        return (getFoo() + getBar()).hashCode();
    }

    public String getFoo() {
        return foo;
    }

    public String getBar() {
        return bar;
    }
}

最重要的是保持hashCode()和equals()的一致性:如果equals()对于两个对象返回true，那么hashCode()应该返回相同的值。如果equals()返回false，那么hashCode()应该返回不同的值。

标准实现很弱，使用它会导致不必要的冲突。想象一个

class ListPair {
    List<Integer> first;
    List<Integer> second;

    ListPair(List<Integer> first, List<Integer> second) {
        this.first = first;
        this.second = second;
    }

    public int hashCode() {
        return Objects.hashCode(first, second);
    }

    ...
}

Now,

new ListPair(List.of(a), List.of(b, c))

and

new ListPair(List.of(b), List.of(a, c))

List的乘数具有相同的hashCode，即31*(a+b) + c。hashCode在这里被重用。显然，碰撞是不可避免的，但产生不必要的碰撞只是……不必要的。

There's nothing substantially smart about using 31. The multiplier must be odd in order to avoid losing information (any even multiplier loses at least the most significant bit, multiples of four lose two, etc.). Any odd multiplier is usable. Small multipliers may lead to faster computation (the JIT can use shifts and additions), but given that multiplication has latency of only three cycles on modern Intel/AMD, this hardly matters. Small multipliers also leads to more collision for small inputs, which may be a problem sometimes.

使用质数是没有意义的，因为质数在环Z/(2**32)中没有意义。

因此，我建议使用随机选择的大奇数(可以选择质数)。由于i86/amd64 cpu可以使用更短的指令来匹配一个有符号字节的操作数，因此对于像109这样的乘法器来说，速度优势很小。为了最小化冲突，可以使用类似0x58a54cf5的值。

在不同的地方使用不同的乘数是有帮助的，但可能不足以证明额外的工作是合理的。