속도야 빨라지겠지만, 해시 품질이 나빠져 해시테이블의 성능을 심각하게 떨어트릴 수도 있다.
특히 어떤 필드는 특정 영역에 몰린 인스턴스들의 해시코드를 넓은 범위로 코르게 퍼트려 주는 효과가 있을지도 모른다.
하필 이런 필드를 생략한다면 해당 영역의 수많은 인스턴스가 단 몇개의 해시코드로 집중되어 해시테이블의 속도가 선형으로 느려질 것이다.
실제로 자바2전의 String은 최대 16개의 문자만으로 해시코드를 계산했다.
문자열이 길면 균일하게 나눠 16문자만 뽑아내 사용한 것이다.
URL처럼 계층적인 이름을 대량으로 사용한다면 이런 해시 함수는 앞서 이야기한 심각한 문제를 고스란히 드러낸다
ex) https://kkimsungchul.github.io/asp/2023/03/23/IIS-URL-%EC%9E%AC%EC%9E%91%EC%84%B1-%EA%B8%B0%EB%8A%A5-%EC%B6%94%EA%B0%80.html
위의 URL이면 "https://kkimsung" 이부분만 잘라서 만든것임
그래야 클라이언트가 이 값에 의지하지 않게 되고, 추후 계산방식을 바꿀 수 도 있다.
String과 Integer를 포함해, 자바 라이브러리의 많은 클래스에서 hashCode 메소드가 반환하는 정확한 값을 알려준다.
바람직하지 않은 실수지만 바로잡기에는 이미 늦었다.
향후 릴리스에서 해시 기능을 개선할 여지도 없애버렸다.
자세한 규칙을 공표하지 않는다면, 해시 기능에서 결함을 발견했거나, 더 나은 해시 방식을 알아낸 경우다음 릴리스에서 수정할 수 있다.
equals를 재정의할 때는 hashCode도 반드시 재정의해야 한다.그렇지 않으면 프로그램이 제대로 동작하지 않을 것이다.
재정의한 hashCode는 Object의 API문서에 기술된 일반 규약을 따라야 하며, 서로 다른 인스턴스라면 되도록 해시코드도 서로 다르게 구현해야 한다.
쉽게 IntelliJ나 Eclipse 에서 제공해주는 것을 사용해도 된다.