java代码优化equal_java代码优化——覆盖equals时总要覆盖hashCode

HashCode规范

一个很常见的错误根源在于没有覆盖hashCode方法。在每个覆盖了equals方法的类中，也必须覆盖hashCode方法。如果不这样的话，就会违反Object.hashCode的通用约定，从而导致该类无法结合所有基于散列的集合一起愉快的正常运作，这样的集合包括HashMap，HashSet以及Hashtable。

下面是约定的内容，Object规范[JavaSE6]：

1.在应用程序的执行期间，只要对象的equals方法的比较操作所用的信息没有被修改，那么对这个对象调用多次，hashCode方法都必须始终如一地返回同一个整数。在同一个应用程序的多次执行过程中，每次执行所返回的整数可以不一致。

2.如果两个对象根据equals(Object)方法比较结果相等的，那么调用这两个对象中任意一个对象的hashCode方法都必须产生同样的整数结果。

3.如果两个对象根据equals(Object)方法比较是不相等的，那么调用这两个对象中任意一个对象的hashCode方法不一定要产生不一样的整数结果。但是我们应该知道，给不相等的对象产生不相同的整数结果，可以提高散列表(hashtable)的性能。

未覆盖hashCode()方法的后果

因为没有覆盖hashCode而违反的关键约定是第二条：相等的对象必须具有相等的散列码(hash code)。

根据类的equals方法，两个截然不同的实例在逻辑上有可能是相等的，但是根据Object类的hashCode方法，它们仅仅是两个没有任何共同之处的对象。因此，对象的hashCode方法返回两个看起来是随机的整数，而不是根据第二个约定那样，返回两个相等的整数。

例如下面这个例子：

public final class PhoneNumber {

private final short areaCode;

private final short prefix;

private final short lineNumber;

public PhoneNumber(int areaCode, int prefix,

int lineNumber) {

rangeCheck(areaCode, 999, "area code");

rangeCheck(prefix, 999, "prefix");

rangeCheck(lineNumber, 9999, "lineNumber");

this.areaCode = (short) areaCode;

this.prefix = (short) prefix;

this.lineNumber = (short) lineNumber;

}

private static void rangeCheck(int arg, int max, String name) {

if (arg < 0 || arg > max)

throw new IllegalArgumentException(name + ":" + arg);

}

@Override

public boolean equals(Object o) {

if (this == o)

return true;

if (!(o instanceof PhoneNumber))

return false;

PhoneNumber pn = (PhoneNumber) o;

return pn.lineNumber == lineNumber

&& pn.prefix == prefix

&& pn.areaCode == areaCode;

}

}

如果和HashMap一起使用，则会出现问题。

Map m = new HashMap();

m.put(new PhoneNumber(707, 867, 5309), "Jenny");

System.out.println(m.get(new PhoneNumber(707, 867, 5309)));

输出结果为：

null

由于PhoneNumber类中没有重写hashCode方法，即使两个PhoneNumber实例是相等的(通过equals()方法比较相等)，但是两个相等的类不具有相同的散列码，违反了hashCode的约定。因此，put方法把电话号码对象存放在一个散列桶(hash bucket)中，get方法却在另外一个散列桶里面查找。即使这两个实例正好被放到了同一个散列桶里面，get方法也一定会返回null，因为HashMap做了一项优化，将每个项相关联的散列码存放起来，如果hash码不匹配，则不会去检验对象的等同性，充分利用了逻辑与运算的惰性(&&)。

如何覆盖hashCode()方法

修正这个问题也非常的简单，只需要为PhoneNumber类提供了一个适当的hashCode方法即可。编写一个合法但是并不好用的hashCode方法并没有任何的价值，例如下面的这个hashCode()方法：

@Override

public int hashCode() { return 42;}

上面这个方法虽然是合法的，因为它确保了相等的对象总是具有同样的散列码。但是对于每个实例对象的散列码是相同的= =。因此，每个对象都被映射到了同一个散列桶中，散列表退化成链表。使得本该以线性时间运行的程序似乎变成了以方级时间在运行。

一个好的散列函数通常倾向于“为不相等的对象产生不相等的散列码”。这正是hashCode约定中的第三条含义。在理想的情况下，散列函数应该把集合中不相等的实例均匀的分不到所有可能的散列值上。要想达到理想的情况是非常困难的，幸运的是相对接近理想情况并不太困难，例如下面的这种解决方法：

把某个非零的常数值，比如说17，保存到一个名为result的int类型变量中。

对于对象中每个关键域f (指equals方法中涉及的每个域)，完下面的步骤：

a. 为该域计算int类型的散列码c:

i. 如果该域是boolean类型的，则计算(f ? 1 : 0)

ii. 如果该域是byte、char、short、或者int类型的，则计算(int)f。

iii. 如果是long类型的，则计算(int)(f^(f>>>32))。

iv. 如果该域是float类型，则计算FLoat.floatToIntBits(f)。

v. 如果该域是double类型，则计算Double.doubleToLongBits(f)，然后按照步骤2.a.iii，为得到long类型值计算散列值。

vi. 如果该域是一个对象引用，并且该类的equals方法通过递归地调用equals的方式来比较这个域，则同样为这个域递归地调用hashCode。如果需要更复杂的比较，则为这个域计算一个范式(canonical representation)，然后针对这个范式调用hashCode。如果这个域为null,则返回0。

vii. 如果该域是一个数组，则要把每个元素当作单独的域来处理。

b. 按照下面的公式，将2.a计算得到的散列码c合并到result中：

result = 31 * result + c;

3.返回result。

4.写完了之后，检查是否符合上述的三条规定。

在散列码的计算过程中，可以把冗余域(redundant field)排除在外。换句话说，如果一个域的值可以根据参与计算的其他域计算出来，则可以把这样的域排除在外。必须排除equals比较计算中没有用到的域，否则很有可能违反hashCode约定中的第二条了。

在计算过程中选择31的原因，是因为31有个很好的性能，现代的JVM可以自动的优化计算过程，将31 * i优化成为(i << 5) - i。用位运算和减法替代了乘法。

下面开始为PhoneNumber类编写hashCode()方法。其中有三个关键域，都是short类型的，根据上面的规则2.a.ii,则hashCode代码如下：

@Override

public int hashCode() {

int result = 17;

result = 31 * result + areaCode;

result = 31 * result + prefix;

result = 31 * result + lineNumber;

return result;

}

如果一个类是不可变的，并且计算散列码的开销比较大，就应该考虑把散列码缓存在对象内部，而不是每次请求的时候都重新计算散列码。如果你就得这种类型的大多数对象会被用作散列键，就应该在创建实例的时候计算散列码。否则，可以选择“延迟初始化”散列码，一直到hashCode被第一次调用的时候才初始化。

//Lzzily initialized, cached hashCode

private volatile int hashCode;

@Override public int hashCode(){

int result = hashCode;

if(result == 0){

int result = 17;

result = 31 * result + areaCode;

result = 31 * result + prefix;

result = 31 * result + lineNumber;

}

return result;

}