Java에서 ==와 equals는 언제 다르게 동작할까
빠른 답
- 객체에서
==는 두 변수가 같은 객체를 가리키는지 확인하는 참조 비교다. equals는 클래스가 정한 논리적 동등성 기준을 실행하는 메서드다.- 직접 만든 값 객체에서
equals를 재정의했다면hashCode도 같은 기준으로 맞춰야 한다. String과Integer에서==가true로 보일 때가 있지만, 캐싱과 재사용의 결과일 수 있어 값 비교 기준으로 삼기 어렵다.
목차
왜 헷갈릴까
Java에서 “같다”는 말은 두 가지 질문으로 나뉜다. 하나는 “두 변수가 같은 객체를 가리키는가?”이고, 다른 하나는 “두 객체를 같은 값으로 볼 수 있는가?”이다.
예를 들어 new Apple(100)을 두 번 호출하면 무게가 같은 사과 객체 두 개가 생긴다. 이 둘은 값 관점에서는 같다고 볼 수 있지만, 객체 자체는 서로 다르다. ==는 앞의 질문, 즉 같은 객체인지 묻는다. equals는 뒤의 질문, 즉 클래스가 정의한 값 기준에 따라 같은지 묻는다.
이 차이는 문법 암기보다 런타임 의미에 가깝다. 변수에는 객체가 직접 들어 있는 것이 아니라 객체를 가리키는 참조가 들어 있고, equals는 그 참조가 가리키는 객체의 메서드로 실행된다.
한눈에 비교
시간 흐름으로 이해하기
이 흐름을 놓치면 “값은 같은데 왜 ==가 false인가?” 또는 “equals는 true인데 왜 HashSet.contains는 false인가?” 같은 출력이 이상하게 보인다.
직접 만든 객체의 동등성 기준
직접 만든 클래스는 기본적으로 Object를 상속한다. 별도로 equals를 재정의하지 않으면 필드 값이 같아도 동등하다고 판단하지 않는다. 기본 equals는 객체 참조가 같은지 보는 쪽에 가깝기 때문이다.
아래 코드는 사과의 동등성 기준을 weight로 정한 예시다. 같은 무게의 사과를 논리적으로 같은 값으로 보겠다는 설계가 코드에 들어 있다.
import java.util.Objects;
public class EqualityDemo {
static final class Apple {
private final int weight;
Apple(int weight) {
this.weight = weight;
}
@Override
public boolean equals(Object o) {
if (this == o) return true;
if (!(o instanceof Apple apple)) return false;
return weight == apple.weight;
}
@Override
public int hashCode() {
return Objects.hash(weight);
}
}
public static void main(String[] args) {
Apple a = new Apple(100);
Apple b = new Apple(100);
Apple c = a;
String s1 = "java";
String s2 = new String("java");
Integer n1 = 128;
Integer n2 = 128;
System.out.println("a == b : " + (a == b));
System.out.println("a == c : " + (a == c));
System.out.println("a.equals(b) : " + a.equals(b));
System.out.println("s1 == s2 : " + (s1 == s2));
System.out.println("s1.equals(s2) : " + s1.equals(s2));
System.out.println("n1 == n2 : " + (n1 == n2));
System.out.println("n1.equals(n2) : " + n1.equals(n2));
}
}
실행하면 다음과 같은 결과를 관찰할 수 있다.
a == b : false
a == c : true
a.equals(b) : true
s1 == s2 : false
s1.equals(s2) : true
n1 == n2 : false
n1.equals(n2) : true
a와 b는 각각 new로 만들어졌기 때문에 서로 다른 객체다. 그래서 a == b는 false다. c는 a를 그대로 대입받았으므로 같은 객체를 가리키고, a == c는 true다. a.equals(b)가 true인 이유는 Apple.equals가 참조가 아니라 weight 값을 비교하도록 구현되어 있기 때문이다.
이때 equals의 기준은 도메인 설계에 속한다. 어떤 클래스는 id만 같으면 같은 객체로 볼 수 있고, 어떤 클래스는 currency와 amount가 모두 같아야 같은 값으로 볼 수 있다. 중요한 것은 equals에 참여하는 필드와 hashCode에 참여하는 필드가 같은 기준을 따라야 한다는 점이다.
String 비교에서 결과가 갈리는 이유
String은 객체지만 리터럴 때문에 특별해 보일 때가 많다. "java" 같은 문자열 리터럴은 문자열 풀에 저장되어 재사용될 수 있다. 그래서 같은 리터럴끼리 ==로 비교하면 true가 나올 수 있다.
하지만 new String("java")는 새 String 객체를 만들겠다는 표현이다. 내용은 같아도 참조는 달라질 수 있다. 따라서 문자열에서 ==가 한 번 true로 보였다고 해서 문자열 값 비교에 ==를 써도 된다는 의미는 아니다.
문자열 비교에서 보통 확인하려는 것은 같은 객체인지가 아니라 같은 문자 시퀀스인지다. 조건문, 요청 파라미터, 설정값, 상태값을 비교할 때는 equals를 사용하는 편이 의도가 분명하다.
String status = new String("READY");
if ("READY".equals(status)) {
System.out.println("start");
}
"READY".equals(status)처럼 리터럴을 앞에 두면 status가 null이어도 NullPointerException이 발생하지 않는다. 다만 null을 조용히 다룰지, null 자체를 오류로 볼지는 별도의 설계 문제다. null이 들어오면 안 되는 값이라면 초기에 검증해서 오류를 드러내는 방식이 더 나을 수 있다.
Integer와 래퍼 클래스의 캐싱
Integer, Long, Boolean 같은 래퍼 타입도 객체다. 따라서 래퍼 객체끼리 ==를 사용하면 값이 아니라 참조를 비교한다.
다만 Integer는 자주 쓰이는 작은 값을 캐싱한다. 일반적으로 오토박싱이나 Integer.valueOf를 거칠 때 -128부터 127까지의 값은 재사용될 수 있다. 그래서 다음과 같은 현상이 나타난다.
Integer a = 127;
Integer b = 127;
Integer c = 128;
Integer d = 128;
System.out.println(a == b);
System.out.println(c == d);
System.out.println(c.equals(d));
관찰되는 출력은 보통 다음과 같다.
true
false
true
127은 캐싱 범위 안이라 같은 객체가 재사용될 수 있고, 128은 그렇지 않을 수 있다. 하지만 이 차이를 비교 규칙으로 외우면 코드가 불안정해진다. 값 비교가 목적이라면 equals를 사용하거나, null이 필요 없는 숫자라면 int, long 같은 원시 타입으로 다루는 편이 의미가 더 분명하다.
hashCode를 함께 맞춰야 하는 이유
equals만 재정의하고 hashCode를 재정의하지 않으면 해시 기반 컬렉션에서 찾기 어려운 버그가 생긴다. 객체끼리 equals로는 같다고 나오는데 HashSet.contains가 false를 반환하는 식이다.
아래 코드는 equals만 재정의한 잘못된 예시다.
import java.util.HashSet;
import java.util.Set;
public class BrokenHashCodeDemo {
static final class Product {
private final String code;
Product(String code) {
this.code = code;
}
@Override
public boolean equals(Object o) {
if (this == o) return true;
if (!(o instanceof Product product)) return false;
return code.equals(product.code);
}
}
public static void main(String[] args) {
Product saved = new Product("A-001");
Product searched = new Product("A-001");
Set<Product> products = new HashSet<>();
products.add(saved);
System.out.println("equals : " + saved.equals(searched));
System.out.println("set contains : " + products.contains(searched));
}
}
실행 결과는 다음처럼 어긋날 수 있다.
equals : true
set contains : false
두 Product는 code가 같으므로 equals 결과는 true다. 하지만 hashCode는 재정의하지 않았기 때문에 두 객체가 서로 다른 해시 위치를 가리킬 수 있다. HashSet은 먼저 해시값으로 후보 위치를 찾고, 그 위치 안에서 equals를 확인한다. 애초에 다른 위치를 찾으면 equals까지 도달하지 못한다.
이 문제를 줄이려면 다음 기준을 같이 맞춰야 한다.
equals가true인 두 객체는 반드시 같은hashCode를 반환해야 한다.equals에 사용하는 필드와hashCode에 사용하는 필드는 같은 동등성 기준을 따라야 한다.- 해시 컬렉션에 넣은 뒤 바뀔 수 있는 필드는 동등성 기준에 넣을 때 주의가 필요하다.
- 값 객체라면 불변 필드와 생성자 초기화를 우선 고려하면 비교 결과가 안정적이다.
값 객체라면 record도 선택지가 된다
객체의 정체성이 필드 값 자체라면 record가 잘 맞는 경우도 있다. record는 컴포넌트 값을 기준으로 equals와 hashCode를 자동 생성한다.
public record Money(String currency, long amount) {
public static void main(String[] args) {
Money a = new Money("KRW", 1000);
Money b = new Money("KRW", 1000);
System.out.println(a == b);
System.out.println(a.equals(b));
}
}
예상 출력은 다음과 같다.
false
true
a와 b는 서로 다른 객체라서 ==는 false다. 그러나 record가 생성한 equals는 currency와 amount 값을 비교하므로 true가 된다.
직접 클래스를 만들 때도 같은 질문을 먼저 두면 좋다. “이 객체를 같은 값으로 볼 기준은 무엇인가?”, “그 기준은 생성 후 바뀌는가?”, “이 객체가 HashSet이나 HashMap의 키로 쓰이는가?” 같은 질문이다. 비교 동작은 단순한 문법이 아니라 객체의 상태, 컬렉션 조회, 오류 증상까지 이어진다.
흔한 오해
첫 번째 오해는 객체 안의 값이 같으면 ==도 true일 것이라는 생각이다. Java 객체 변수는 객체 자체가 아니라 참조를 담고 있다. 같은 값으로 만들어진 객체라도 참조가 다르면 ==는 false다.
두 번째 오해는 equals가 항상 값 비교를 해준다는 생각이다. 정확히는 클래스가 그렇게 구현했을 때 값 비교가 된다. 직접 만든 클래스가 equals를 재정의하지 않았다면 기본 동작은 참조 비교와 크게 다르지 않다.
세 번째 오해는 한 번의 출력 결과를 일반 규칙으로 받아들이는 것이다. String 리터럴, Integer 캐싱처럼 런타임이 객체를 재사용해서 ==가 true로 보이는 경우가 있다. 이런 결과는 비교 의도와 우연히 맞아떨어진 것일 수 있다.
==는 틀린 연산자가 아니다. 같은 인스턴스인지 확인해야 할 때는 정확한 도구다. 예를 들어 enum 상수 비교, 싱글턴 인스턴스 비교, 객체 별칭 여부 확인에는 ==가 의미에 맞다. 반대로 문자열 내용, 숫자 값, 도메인 식별자, 값 객체를 비교한다면 equals나 명시적인 필드 비교가 더 읽기 쉽고 오류를 줄이기 쉽다.
원문 참고
https://www.maeil-mail.kr/question/71
댓글
댓글 쓰기