java 重写equals方法和hashCode方法

补充一下：

如何重写 hashCode

生成一个 int 类型的变量 result，并且初始化一个值，比如1

对类中每一个重要字段，也就是影响对象的值的字段，也就是 equals 方法里有比较的字段，进行以下操作：a. 计算这个字段的值 filedHashValue = filed.hashCode(); b. 执行 result = 31 * result + filedHashValue;
为什么要使用 31

看一看 String hashCode 方法的源码：

/**
 * Returns a hash code for this string. The hash code for a
 * {@code String} object is computed as
 * <blockquote><pre>
 * s[0]*31^(n-1) + s[1]*31^(n-2) + ... + s[n-1]
 * </pre></blockquote>
 * using {@code int} arithmetic, where {@code s[i]} is the
 * <i>i</i>th character of the string, {@code n} is the length of
 * the string, and {@code ^} indicates exponentiation.
 * (The hash value of the empty string is zero.)
 *
 * @return  a hash code value for this object.
 */
public int hashCode() {
    int h = hash;
    if (h == 0 && value.length > 0) {
        char val[] = value;

        for (int i = 0; i < value.length; i++) {
            h = 31 * h + val[i];
        }
        hash = h;
    }
    return h;
}

可以从注释看出：空字符串的 hashCode 方法返回是 0。并且注释中也给了个公式，可以了解了解。

String 源码中也使用的 31，然后网上说有这两点原因：

原因一：更少的乘积结果冲突

31是质子数中一个“不大不小”的存在，如果你使用的是一个如2的较小质数，那么得出的乘积会在一个很小的范围，很容易造成哈希值的冲突。而如果选择一个100以上的质数，得出的哈希值会超出int的最大范围，这两种都不合适。而如果对超过 50,000 个英文单词（由两个不同版本的 Unix 字典合并而成）进行 hash code 运算，并使用常数 31, 33, 37, 39 和 41 作为乘子，每个常数算出的哈希值冲突数都小于7个（国外大神做的测试），那么这几个数就被作为生成hashCode值得备选乘数了。

所以从 31,33,37,39 等中间选择了 31 的原因看原因二。

原因二：31 可以被 JVM 优化

JVM里最有效的计算方式就是进行位运算了：

* 左移 << : 左边的最高位丢弃，右边补全0（把 << 左边的数据*2的移动次幂）。
　　* 右移 >> : 把>>左边的数据/2的移动次幂。
　　* 无符号右移 >>> : 无论最高位是0还是1，左边补齐0。

   所以 ： 31 * i = (i << 5) - i（左边  31*2=62,右边   2*2^5-2=62） - 两边相等，JVM就可以高效的进行计算啦。。。