[이펙티브 자바] Item11. equals를 재정의하려거든 hashcode도 재정의하라. (hashCode 규약)

 

item11. equals를 재정의하려거든 hashcode도 재정의하라. 

[이펙티브 자바] Item10. equals는 일반 규약을 지켜 재정의하라. (equals 구현 방법과 주의사항) (tistory.com)

[이펙티브 자바] Item10. equals는 일반 규약을 지켜 재정의하라. (equals 구현 방법과 주의사항)

equals를 재정의할 때 hashcode도 반드시 재정의 해야 한다고 주의사항으로 작성해뒀다. 

 

equals를 재정의한 클래스 모두에서 hashcode도 재정의해야하는데 그렇지 않으면 hashcode 일반 규약을 어기게 되어서 해당 클래스의 인스턴스를 HashMap이나 HashSet 같은 컬렉션의 원소로 사용할 때 문제가 발생한다. 

 

 

hashCode 규약

 

1️⃣ equals 비교에 사용하는 정보가 변경되지 않았다면 hashCode는 매번 같은 값을 리턴해야 한다. 

(변경되거나, 애플리케이션을 다시 실행했다면 달라질 수 있다.) 

 

 

2️⃣ 두 객체에 대한 equals가 같다면, hashCode의 값도 같아야 한다. 

 

 

3️⃣ 두 객체에 대한 equals가 다르더라도, hashCode의 값은 같을 수 있지만 해시 테이블 성능을 고려해 다른 값을 리턴하는 것이 좋다. 

 

 

-> 여기서 hashcode 재정의를 잘못했을 때 크게 문제가 되는 곳은 2번째로 논리적으로 같은 객체는 같은 해시코드를 반환해야 한다. 

 

public class PhoneNumber
{
   private final short areaCode, prefix, lineNum;
   
   public PhoneNumber(int areaCode, int prefix, int lineNum)
   {
      this.areaCode = rangeCheck(areaCode, 999, "area code");
      this.prefix = rangeCheck(prefix, 999, "prefix");
      this.lineNum = rangeCheck(lineNum, 9999, "line num");
   }
   
   private static short rangeCheck(int val, int max, String arg)
   {
      if (val < 0 || val > max) {
         throw new IllegalArgumentException(arg + ": " + val);
      }
         return (short) val;
   }
   
   @Override
   public boolean equals(Object o)
   {
      if (this == o)
         return true;
      if (!(o instanceof PhoneNumber)) {
         return false;
      }
      PhoneNumber that = (PhoneNumber) o;
      return areaCode == that.areaCode && prefix == that.prefix && lineNum == that.lineNum;
   }
 }

이렇게 만약 equals는 재정의 했는데 hashcode는 재정의하지 않았더라면 

 

    public static void main(String[] args)
   {
      Map<PhoneNumber, String> map = new WeakHashMap<>();
      PhoneNumber number1 = new PhoneNumber(123, 456, 7890);
      PhoneNumber number2 = new PhoneNumber(123, 456, 7890);
      
      // 같은 인스턴스인데 다른 hashcode
      System.out.println("number1.equals(number2) = " + number1.equals(number2));
      System.out.println("number1.hashCode() = " + number1.hashCode());
      System.out.println("number2.hashCode() = " + number2.hashCode());
      
      map.put(number1, "hyejin");
      map.put(number2, "user");
      
      String s = map.get(number2);
      System.out.println("s = " + s);
      
      String s1 = map.get(new PhoneNumber(123, 456, 7890));
	  System.out.println("s1 = " + s1); // 아무것도 안나옴
      
   }

number1과 number2 를 map에 넣고 map.get(number2)를 할 때는 user을 잘 반환하지만 

밑에 new PhoneNumber(123, 456, 7890)을 get하면 null이 반환된는 것을 확인할 수 있다. 

왜냐하면 hashcode를 같이 재정의하지 않았기 때문에 논리적 동치인 두 객체가 서로 다른 해시코드를 반환하기 때문이다. 

따라서 get 메서드가 해시 코드값이 달라서 다른 곳을 찾아 헤매고 있기 때문에 null을 반환하는 것이다. 

 

📚 HashMap은 해시코드가 다른 엔트리끼리는 동치성 비교 시도조차 하지 않도록 최적화 되어 있기 때문이다. 

 

 

그래서 hashcode를 재정의해야하는데 만약 hashcode 값을 모두 동일하게 작성한다면 ? 

@Override
public int hashCode()
{
   return 42;
}

이 코드는 동치인 모든 객체에서 똑같은 해시코드를 반환하므로 적법하지만 모든 객체에게 똑같은 값을 내어주기 때문에 모든 객체가 해시 테이블의 버킷 하나에 담겨 마치 연걸 리스트 LinkedList처럼 동작한다. 

-> 이렇게 되면 평균 수행 시간이 O(1) 인 해시테이블이 O(n) 으로 느려져서, 객체가 많아지면 도저히 쓸 수 없게 된다. 

 

 

📚 세번째 규약에서 두 객체에 대한 equals가 다르더라도, hashCode의 값은 같을 수 있다고는 했지만 성능상 다른 값을 리턴하는게 좋다고 했다. 좋은 해시 함수라면 서로 다른 인스턴스에 다른 해시코드를 반환한다.