[JAVA] String vs StringBuffer & equals() vs hashCode()

📌 String

• 참조형 타입, Heap 메모리에 저장
• 불변 객체 (Immutable)
  → 문자열 변경 시 기존 객체 수정이 아닌 새 객체 생성
• 문자열 비교 방식
  • == : 주소값 비교
  • equals() : 문자열 값 비교

✔ 불변으로 설계된 이유

1. String Constant Pool 활용으로 캐싱 → 성능 향상
2. 멀티스레드 환경에서 동기화 문제 없음
3. 보안 강화 → 예: DB 비밀번호 같은 민감 데이터 보호

---

📌 String vs StringBuffer vs StringBuilder

 

	String	StringBuffer	StringBuilder
가변성	❌ 불변	✅ 가변	✅ 가변
쓰레드 안전	✅ thread-safe	✅ thread-safe	❌ unsafe
성능	느림	보통	가장 빠름
사용처	변경 거의 없음	멀티스레드 변경 多	단일 스레드 변경 多

 

✔ 핵심 요약

• String : 변경 없는 문자열에 적합
• StringBuffer : 멀티스레드 환경에서 변경 많은 경우
• StringBuilder : 단일 스레드 환경에서 빠른 처리 필요할 때
• 성능 순위 → StringBuilder > StringBuffer > String

 

---

 

📌 equals() vs hashCode()

✅ equals()

• 객체 동등성 비교 메서드
• 기본은 == 처럼 주소 비교
• 오버라이딩 시 필드 값 기준 비교 가능
• 보통 Objects.equals()로 비교 구현

@Override 
public boolean equals(Object o) { 
   if (this == o) return true; 
   if (!(o instanceof Person)) return false;
   
   Person p = (Person) o;
   return Objects.equals(this.name, p.name);
}

---

✅ hashCode()

• 객체의 고유한 정수 해시값 반환
• 기본은 주소 기반, 오버라이딩 시 필드 기반으로 변경 가능
• HashSet, HashMap 등에서 객체 식별 기준

@Override public int hashCode() { 
   return Objects.hash(name); 
}

 

---

⚠ equals만 재정의 시 문제

• HashMap/HashSet 등은
  hashCode() → equals() 순으로 비교
• equals가 true여도 hashCode가 다르면
  중복 판단 못 함 → 데이터 중복 저장됨

---

✅ identityHashCode()

• 오버라이딩된 hashCode() 대신
  원래의 주소 기반 해시코드를 반환
• 사용 예: System.identityHashCode(obj)

---

✅ 정리 요약

 

method	기본동작	오버라이딩 목적	주의사항
equals()	주소 비교	필드 값 비교	hashCode도 함께 오버라이딩
hashCode()	주소 기반 해싱	필드 기반 해싱	equals가 같으면 hashCode도 같아야 함
identityHashCode()	주소 기반 해싱	오버라이딩 무시	객체 실제 식별용