코드 땜장이

Java에서 ==와 equals는 언제 다르게 동작할까 빠른 답 객체에서 == 는 두 변수가 같은 객체를 가리키는지 확인하는 참조 비교다. equals 는 클래스가 정한 논리적 동등성 기준을 실행하는 메서드다. 직접 만든 값 객체에서 equals 를 재정의했다면 hashCode 도 같은 기준으로 맞춰야 한다. String 과 Integer 에서 == 가 true 로 보일 때가 있지만, 캐싱과 재사용의 결과일 수 있어 값 비교 기준으로 삼기 어렵다. 목차 왜 헷갈릴까 한눈에 비교 시간 흐름으로 이해하기 직접 만든 객체의 동등성 기준 String 비교에서 결과가 갈리는 이유 Integer와 래퍼 클래스의 캐싱 hashCode를 함께 맞춰야 하는 이유 값 객체라면 record도 선택지가 된다 흔한 오해 왜 헷갈릴까 Java에서 “같다”는 말은 두 가지 질문으로 나뉜다. 하나는 “두 변수가 같은 객체를 가리키는가?”이고, 다른 하나는 “두 객체를 같은 값으로 볼 수 있는가?”이다. 예를 들어 new Apple(100) 을 두 번 호출하면 무게가 같은 사과 객체 두 개가 생긴다. 이 둘은 값 관점에서는 같다고 볼 수 있지만, 객체 자체는 서로 다르다. == 는 앞의 질문, 즉 같은 객체인지 묻는다. equals 는 뒤의 질문, 즉 클래스가 정의한 값 기준에 따라 같은지 묻는다. 이 차이는 문법 암기보다 런타임 의미에 가깝다. 변수에는 객체가 직접 들어 있는 것이 아니라 객체를 가리키는 참조가 들어 있고, equals 는 그 참조가 가리키는 객체의 메서드로 실행된다. 한눈에 비교 비교 기준 == 는 참조를 비교하고, equals 는 클래스가 정의한 동등성 기준을 비교한다. 기본 동작 Object.equals 는 기본적으로 this == obj 와 같은 참조 비교 의미를 가진다. 변경 가능성 == 의 동작은 바꿀 수 없지만, equals 는 클래스에서 재정의할 수 있다. 컬렉션 영향 HashSet , HashMap 은 hashCode 로 후보 위치를...

equals와 hashCode를 함께 구현해야 HashSet과 HashMap이 제대로 동작하는 이유 빠른 답 equals 를 재정의했다면 hashCode 도 같은 기준 필드로 재정의해야 합니다. HashSet 과 HashMap 은 먼저 hashCode 로 후보 위치를 좁힌 뒤 equals 로 최종 비교합니다. equals 가 true 인 두 객체는 항상 같은 hashCode 를 반환해야 합니다. 해시 계산에 쓰이는 필드는 컬렉션에 넣은 뒤 바뀌지 않는 값으로 잡는 편이 안전합니다. 목차 흐름으로 보기 값, 상태, 오류 유형 구분하기 동일성과 동등성 equals만 재정의했을 때 생기는 결과 equals와 hashCode를 함께 구현하기 해시 충돌과 흔한 오해 변경 가능한 필드를 기준으로 삼을 때의 위험 자동 점검과 구성 예시 디버깅할 때 볼 출력 흐름으로 보기 흐름 다이어그램 해시 기반 컬렉션은 객체를 넣거나 찾을 때 모든 원소를 처음부터 끝까지 equals 로 비교하지 않습니다. 먼저 hashCode 를 이용해 내부 저장 공간 중 확인할 위치를 좁힙니다. 그다음 같은 위치에 있는 후보들만 equals 로 비교합니다. 이 순서 때문에 equals 만 재정의한 객체는 일반 비교에서는 같아 보여도 HashSet , HashMap 안에서는 서로 다른 객체처럼 다뤄질 수 있습니다. equals 가 호출되기 전에 hashCode 가 다른 버킷을 가리켜 버리면, 같은 값인지 확인할 기회가 생기지 않기 때문입니다. 값, 상태, 오류 유형 구분하기 Java에서 객체 비교를 이야기할 때는 값, 상태, 오류 유형을 나누어 보면 덜 헷갈립니다. 값은 객체를 논리적으로 같다고 볼 때 사용하는 기준입니다. 예를 들어 구독자를 email 과 category 로 구분한다면, 두 필드가 같은 두 객체는 같은 구독자라고 볼 수 있습니다. 상태는 객체가 현재 들고 있는 필드 값입니다. email 이나 category 가 바뀔 수 있는 필드라면 객체의 동등성도 실행 ...