スポンサーリンク
super.hashCodeの注意点についての日本語情報が見当たらなかったので、メモしておきます。
詳しい人が途中まで読んで「そんだけか」とがっかりしないために結論を言ってしまうと、「super.hashCodeがObject#hashCodeだった場合、インスタンスごとに違う値が返って来ちゃって、その値を利用して実装したhashCode実装は、インスタンスごとに違う値を返してしまう」ということです。
目次
スポンサーリンク
こんなことが起こった
HashSetにオブジェクトをaddしたのち、equalsメソッド的に等しいはずのオブジェクトでcontainsを実行してみたところ、なぜか「false」が返ってきました。
equalsの実装は間違ってなさそう…
equalsの実装は間違ってなさそうでした。そこで、よく見るためにLine Breakpointを仕込んでみると、そもそも呼び出されていないことに気が付きました。
HashSetはhashCodeを使う
HashSetは、containsの内部でequalsを用いて比較する前に、とりあえずhashCodeメソッドの戻りとを利用して、等しい可能性があるかをチェックします。hashCodeの値が違っていれば、そもそもequalsを使うまでもなく「等しくない」と判断します。
そう、今回は、equalsでは等しいオブジェクトでも、hashCodeの値が食い違っていたのが、containsでfalseが返ってしまう原因でした。
hashCodeの間違い
ここからが本題です。
なぜhashCodeが間違っていたのかを説明するために、間違いのあるhashCodeの実装を、簡単に１行にして書いてみます。
@Override
public int hashCode() {
return 31 * super.hashCode() + this.name.hashCode();
}
superクラスのhashCodeを利用しつつ、クラスの持つ唯一のフィールドであるname:StringのhashCodeの値を加えていました。
こうすることで、「このオブジェクトが等しいときは、親クラスでhashCodeが等しくて、かつthis.nameのhashCodeが等しいだろう」という考えを表現していました。しかし、これが間違いでした。
ObjectのhashCode実装
実は、このクラスの親クラスはObjectでした。つまり、特に親クラスを指定していなかった状態です。こういうクラスはたくさんあると思います（全ての親クラスがequals・hashCodeを実装していない場合も含む）。
つまり、先ほどの「super.hashCode()」は、「ObjectクラスのhashCode」が呼び出されることになります。
ObjectクラスのhashCodeはJNIを使って実装されておりObject.javaには「public native int hashCode();」としか書かれていないのですが、docコメントにはこう書かれています。
As much as is reasonably practical, the hashCode method defined by class Object does return distinct integers for distinct objects. (This is typically implemented by converting the internal address of the object into an integer, but this implementation technique is not required by the JavaTM programming language.)
Objectのequalsがオブジェクトのアドレス比較（インスタンス一致チェック、==）であることから推測はつくのですが、Object#hashCode()の戻り値は、オブジェクトのアドレスを利用して生成されるため、インスタンスが違えば、hashCode()の値も違うのです。
うかつにsuper.hashCodeを使うと
つまり、うかつにsuper.hashCodeを使ってhashCodeを実装してしまい、なおかつ親クラスがObjectクラスだった場合、（たとえequals的に一致していたとしても、）インスタンスが同じでないと、別のhash値を返してしまうのです。
equalsとhashCode実装の基本
Effective Java
参考
英語だと、この間違え方に触れているページがありました。
スポンサーリンク
スポンサーリンク