最好的实现?这是一个很难回答的问题，因为这取决于使用模式。

Josh Bloch的Effective Java在第8项(第二版)中提出了几乎所有情况下合理的良好实现。最好的办法是去查一下，因为作者在那里解释了为什么这种方法是好的。

简短的版本

Create a int result and assign a non-zero value. For every field f tested in the equals() method, calculate a hash code c by: If the field f is a boolean: calculate (f ? 0 : 1); If the field f is a byte, char, short or int: calculate (int)f; If the field f is a long: calculate (int)(f ^ (f >>> 32)); If the field f is a float: calculate Float.floatToIntBits(f); If the field f is a double: calculate Double.doubleToLongBits(f) and handle the return value like every long value; If the field f is an object: Use the result of the hashCode() method or 0 if f == null; If the field f is an array: see every field as separate element and calculate the hash value in a recursive fashion and combine the values as described next. Combine the hash value c with result: result = 37 * result + c Return result

这将导致在大多数使用情况下哈希值的适当分布。

由于您特别要求集合，我想添加一个其他答案还没有提到的方面:HashMap不期望它们的键在添加到集合后改变它们的hashcode。会破坏整个目的…

我更喜欢使用实用工具方法从谷歌集合库从类对象，帮助我保持我的代码干净。equals和hashcode方法通常都是从IDE的模板中创建的，所以它们的可读性不太好。

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

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的值。

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

如果我正确理解你的问题，你有一个自定义的集合类(即一个从集合接口扩展的新类)，你想实现hashCode()方法。

如果您的集合类扩展了AbstractList，那么您就不必担心它，因为已经有equals()和hashCode()的实现，它通过遍历所有对象并将它们的hashCodes()相加来工作。

   public int hashCode() {
      int hashCode = 1;
      Iterator i = iterator();
      while (i.hasNext()) {
        Object obj = i.next();
        hashCode = 31*hashCode + (obj==null ? 0 : obj.hashCode());
      }
  return hashCode;
   }

现在，如果你想要的是计算特定类哈希码的最佳方法，我通常使用^(按位排他或)操作符来处理我在equals方法中使用的所有字段:

public int hashCode(){
   return intMember ^ (stringField != null ? stringField.hashCode() : 0);
}

使用Apache Commons EqualsBuilder和HashCodeBuilder上的反射方法。