Tech Log 🛠️

Gradle 이란?

자바를 이용해서 코딩을 하다보면 Gradle 을 사용해서 빌드하는 경험을 많이 한다.

근데 이 Gradle 은 정확히 어떤 역할을 할까?

공식문서를 먼저 찾아보면,

Gradle is an open-source build automation tool flexible enough to build almost any type of software.

Gradle 은 스스로 빌드 자동화(build automation) 툴이라고 소개하고 있다.

🧐 빌드란 무엇일까?

자바코드를 컴파일 과정을 거쳐서 컴퓨터가 실행할 수 있는 파일로 만들어 주는 과정을 말한다.

그렇다면 일단 Gradle이 이러한 과정을 관리해줌으로써 개발자의 삶을 좀 더 윤택하게 해준다는 것은 알거같다.

구체적으로 Gradle은 다음과 같은 일을 한다. (스프링 기준)

Compile

- 자바 파일을 컴퓨터가 읽을 수 있는 바이트 코드로 변환해준다.

Test

- 프로그램이 제대로 돌아갈 수 있는 지에 대한 테스트를 지원해준다.

Pakaging

- 컴파일 된 코드로 실행 파일을 만든다.

Deploy & Run

- 실제로 프로그램을 실행시킨다. 예를 들면 스프링 서버를 돌리는 것과 같다.

하지만 Gradle이 다른 툴과 비교했을 때 어떤 장점이 있어서 많은 개발자들이 사용하는 걸까?

Gradle, 왜 쓰는 걸까?

다른 툴들과 비교해봤을 때 Gradle이 가지는 장점이 몇가지 있다.

그 장점들에 대해서 하나씩 알아보자

간결한 스크립트

Gradle의 장점은 먼저 스크립트만 봐도 알 수 있다.

먼저 경쟁자인 Maven의 스크립트를 보자 !

Maven의 경우에는 XML 형식의 스크립트 구조를 사용하고 있어서 가독성도 떨어지고 작성하기도 어렵다.

하지만 Gradle 같은 경우 설정 주입 방식으로 스크립트를 작성해줌으로써 가독성도 좋아지고 프로젝트 구조를 보다 쉽게 파악할 수 있다.

멀티 프로젝트 빌드

프로젝트를 진행하다 보면 여러 개의 모듈로 구성되는 경우가 많다.

하지만 이 때 여러 개의 모듈을 따로 빌드하게 되면 번거롭기도 하고 실수할 가능성도 생긴다.

Gradle은 이런 문제를 해결하기 위해 여러 개의 모듈들을 동시에 빌드할 수 있다.

또한 모듈마다 공통된 코드 , 별도의 코드를 분리해 줌으로써 코드의 중복을 줄일 수 있다.

빠른 빌드 속도

위에서 말한 것들만 모두 해준다고 해도 충분히 쓸만한 툴이다.

근데 여기에 속도까지 빠르다면 ? 그 어려운 걸 Gradle 이 다시 해내버렸다.

표를 보면 Gradle 은 경쟁사 대비 월등히 빠른 속도를 보여주고 있다.

편리하고 빠른 Gradle .. 안 쓸 이유가 없지 않을까?

잠깐 Gradle 은 대체 어떻게 만들었길래 빠른걸까?

Gradle, 왜 빠른 걸까?

다시 Gradle의 공식 문서를 보자

Gradle avoids unnecessary work by only running tasks that need to do work because inputs or outputs have changed. Gradle uses various caches to reuse outputs from previous builds. With a shared build cache, you can even reuse outputs from other machines.

이 문장을 요약하면 Gradle은 기본적으로 불필요한 작업을 방지하고 캐시를 통해 재사용한다는 것을 알 수 있다.

이것을 구현하는 방법은 대표적으로 3가지가 있다.

점진적 빌드

빌드를 할 때 모든 파일들을 다시 빌드하는 게 아닌 , 바뀐 파일들만 추적해서 해당 파일만 빌드하는 것을 말한다.

예를 들어 20개의 파일을 빌드할 때 15개의 파일이 그대로면 나머지 5개의 파일만 빌드하는 형식이다.

빌드 캐시

여러 번의 빌드를 실행할 때 Gradle은 이미 빌드가 된 결과물들을 빌드 캐시에 담아놓는다.

추후에 해당 파일에 대해 다시 빌드를 하게 되면, 다시 빌드할 필요성을 줄여줌으로써 빌드를 더욱 빨리할 수 있다.

혹은 빌드 캐시를 로컬에서만 사용하는 것이 아닌 , 팀원들끼리 빌드 캐시를 공유해서 빌드 결과들을 캐시에 담아 재사용할 수 있다.

데몬 프로세스

데몬 프로세스를 알아보기 전에 데몬은 무엇일까?

Gradle에서 또 친절하게 데몬의 정의를 말해주고 있다.

A daemon is a computer program that runs as a background process, rather than being under the direct control of an interactive user.

해석하자면 , 데몬은 사용자가 직접 제어하지 않고 백그라운드 프로세스로 돌아가는 프로그램이다.

이것을 빌드에 어떻게 도입했을까?

Gradle은 JVM이라는 가상 장치 위에서 실행되며 이 JVM은 여러 초기화 라이브러리들을 사용하며, 이 과정은 꽤 시간이 걸릴 수 있다.

때문에 매번 새로 빌드하는 것이 아닌 동일한 빌드는 이미 실행중인 데몬을 이용하여서 빌드 시간을 줄여준다.

예를 들어서 노트북을 사용하지 않을 때 아예 끄는 것이 아니라 다음 사용을 위해 슬립 모드로 두는 것과 같다.

Gradle, 어떻게 쓰는 걸까?

이렇게 좋은 Gradle , 어떻게 쓰는 지 정도는 알아보자 !

오늘은 빌드 스크립트에서 의존성을 설정하는 부분을 알아볼 것이다.

의존성 설정을 위해선 build.gradle의 dependencies 부분을 봐야한다.

Gradle에선 예시 코드처럼 간편하게 의존성을 설정할 수 있다.

근데 앞에 있는 코드를 보면 모두 다른 코드를 사용하고 있다.

이 코드들은 왜 있고 어떤 기능들을 수행하는 지 알아보자!

compileOnly

컴파일 시에만 의존성을 정의한다.

예를 들어 롬복같은 경우 , 어노테이션을 보고 getter , setter를 컴파일 해주고 런타임에는 넣지 않는다.

runtimeOnly

런타임 시에만 의존성을 정의한다.

예를 들어 DB관련 혹은 로그 의존성 주입 시에 사용한다.

test

앞에 test가 붙어있으면 해당 의존성을 테스트 시에만 사용한다는 의미이다.

의존성이란?

모듈 간의 관계를 예로 들면, A 모듈이 B 모듈을 사용하고 있다.

이것을 A 모듈이 B 모듈에 의존하고 있다고 말한다.

즉 의존성이란 모듈 간 서로 사용하는 관계이다.

Api vs Implementation

dependencies를 보면 api 도 있고 implementation도 있다.

둘은 어떤 차이가 있을까?

먼저 전이 의존성이란 개념을 짚고 넘어갈 필요가 있다.

만약 서로 의존하고 있는 모듈 3개가 있다고 가정하자

여기서 A 모듈이 변경된다면 나머지 모듈들은 어떻게 될까?

만약 여기서 의존하고 있는 모듈들이 모두 영향을 받는다면 전이 의존성이 허용된 경우이다.

여기서 말한 전이 의존성의 특성을 가지고 있는 지가 차이를 결정한다.

공식 문서를 참고해보자

api 또는 compile(지원 중단됨) 대신 이 종속 항목 구성을 사용하면 빌드 시스템에서 다시 컴파일해야 하는 모듈 수가 줄어들기 때문에 빌드 시간이 크게 개선될 수 있습니다.

예를 들어 implementation 종속 항목이 API를 변경하면 Gradle은 이 종속 항목과 이에 직접적으로 종속된 모듈만 다시 컴파일합니다. 대부분의 앱과 테스트 모듈은 이 구성을 사용해야 합니다.

implementation을 사용하면, 종속 항목과 직접적으로 종속된 모듈만 다시 컴파일한다고 나와있다.

그래서 모듈 하나가 변경 된다고 해서 다른 모듈들까지 모두 영향을 주지 않는 것이다.

즉 전이 의존성을 가지지 않는다고 할 수 있다.

반대로 api는 전이 의존성을 가지기 때문에 의존하고 있는 모든 모듈들이 영향을 받고 이것은 곧 컴파일 시간에 영향을 준다.

왜 api를 사용하면 다른 모듈들까지 영향을 받을까?

API는 컴파일 class-path 에도 노출되어 있기 때문에 컴파일 시에 다른 모듈들이 영향을 받게 된다.

하지만 implementation은 런타임 class-path 에만 노출이 되어 있기 때문에 다시 컴파일 할 필요가 없다.

🧐 두 가지 class-path 의 차이를 알아보자

컴파일 class-path : Java 코드를 class 파일로 컴파일 할 때 탐색하는 경로

런타임 class-path : 컴파일 된 자바 코드를 JVM이 실행할 때 탐색하는 경로

정리하자면,

api 는 컴파일 class-path , 런타임 class-path 에 노출된다.

implementation은 런타임 class-path에만 노출된다.

implementation을 사용하면 꽤 많은 장점들이 있다.

1. 컴파일 , 런타임 class-path를 분류함으로써 더 빠른 컴파일이 가능하다.
2. 컴파일 시에 다른 모듈에서 원치않는 라이브러리까지 의존할 필요가 없다.

JVM이란?

자바를 가지고 코딩을 하는 사람은 한번 쯤 JVM 이란 단어를 들어왔을 것이다.

이 JVM은 컴퓨터와의 소통을 도와주는데, 어떤 식으로 소통을 도와주는 지 단계별로 살펴보자

먼저 우리가 코딩을 하고 컴파일러를 통해서 컴파일하면 .class 파일이 생성된다.

현재 이 클래스 파일은 기계어가 아닌 바이트 코드로 되어있다.

바이트 코드란 무엇일까?

JVM이 이해할 수 있는 언어로 변환된 자바 소스코드이다.

언제 어디서든 운영체제에 관계없이 JVM 위에서 실행될 수 있다.

예를 들어 아래의 코드는

System.out.println("Hello World");

다음과 같은 바이트 코드를 가진다.

// class version 61.0 (61)
// access flags 0x21
public class Main {

  // compiled from: Main.java

  // access flags 0x1
  public <init>()V
   L0
    LINENUMBER 8 L0
    ALOAD 0
    INVOKESPECIAL java/lang/Object.<init> ()V
    RETURN
   L1
    LOCALVARIABLE this LMain; L0 L1 0
    MAXSTACK = 1
    MAXLOCALS = 1

  // access flags 0x9
  public static main([Ljava/lang/String;)V
   L0
    LINENUMBER 10 L0
    GETSTATIC java/lang/System.out : Ljava/io/PrintStream;
    LDC "hello world"
    INVOKEVIRTUAL java/io/PrintStream.println (Ljava/lang/String;)V
   L1
    LINENUMBER 11 L1
    RETURN
   L2
    LOCALVARIABLE args [Ljava/lang/String; L0 L2 0
    MAXSTACK = 2
    MAXLOCALS = 1
}

이렇게 바이트 코드로 변환 된 클래스 파일을 JVM에게 전달한다.

JVM은 이 형식의 파일을 가지고 있다가 필요할 때 기계어로 번역을 해서 제공한다.

즉 JVM은 컴파일러와 컴퓨터 사이에 통역가 같은 역할을 해준다고 보면 된다.

기존 c,c++ 컴파일러와는 뭐가 다를까?

근데 하나 의문점이 생겼다.

다른 언어들도 마찬가지로 문장으로 코딩을 하는데 왜 자바만 JVM이란 것을 사용할까?

printf("Hello World");

분명 c언어도 다음과 같이 코딩을 하는데 c언어도 JVM 같은 것을 사용할까?

결론은 “아니다”

이는 언어가 추구하는 방식과 컴파일 방식의 차이 때문이다.

c나 c++ 같은 언어들은 소스코드를 기계가 바로 알아들을 수 있는 바이너리 코드로 번역해준다.

여기서 문제가 하나 있는데 모든 컴퓨터 운영체제들이 같은 언어를 쓰는 것이 아니란 거다.

이로 인해 맥에서 컴파일한 파일이 윈도우나 리눅스에서는 안 돌아가는 문제가 생긴다.

왜냐하면 c나 c++은 각 머신에 맞는 기계어로 바로 컴파일을 해준다.

속도 면에서는 빠를 지 몰라도 다른 환경과의 호환성을 떨어진다.

하지만 JVM은 WORA 라는 철학에 기반을 두고 만들어졌다.

*WORA

Write Once Run Anywhere

한번 쓰고 어디든 돌아간다.

이런 특징 덕분에 자바는 운영체제 관계없이 동일하게 실행할 수 있다.

JRE , JDK 와의 관계

JVM과 이름이 비슷한 JRE,JDK는 어떤 관계일까?

결론 적으로 말하면 JVM이 제일 작고 서로 포함되는 관계이다.

아래 그림을 보자

JVM은 위에서 설명한대로 바이트코드를 기계어로 바꿔준다.

JRE는 런타임에 필요한 여러 라이브러리 , 파일들을 포함한다.

JDK는 그 외 개발에 필요한 디버깅 , 컴파일 같은 기능들을 제공한다.

JVM 특징 정리

• 스택 기반의 가상 머신이다.
• 심볼릭 레퍼런스
  • 객체를 참조할 때 메모리 주소를 참조하는 게 아닌, 이름으로 참조한다.

• 가비지 컬렉션
  • 더 이상 할당되지 않는 데이터의 메모리를 해제해준다.

• 기본 자료형을 명확하게 정의하여 플랫폼 독립성 보장
  • 기본 자료형을 명확하게 정의하여 호환성을 유지하고 플랫폼 독립성을 보장한다.

• 네트워크 바이트 오더
  • 빅 엔디안 바이트 주소를 사용해서 통신을 한다.

빅 엔디안 표기법이란?

0x12 0x34 0x56 0x78 과 같이 낮은 주소부터 높은 주소 순으로 표기하는 방식

JVM 명세

JVM 공식 문서를 보면 다음과 같이 나와있다.

To implement the Java Virtual Machine correctly, you need only be able to

read the class file format and correctly perform the operations specified therein. Implementation details that are not part of the Java Virtual Machine's specification would unnecessarily constrain the creativity of implementors.

요약을 해보면 , 구현자의 창의성을 저해할 수 있기 때문에 기본적인 명세를 제외한 세세한 부분은 정하지 않았다는 것이다.

흔히 행동만 추상화 해두고 구현 책임은 벤더사들에게 맡긴 거라고 볼 수 있다.

그 결과 무수한 JVM 벤더사들이 구현을 시작하였고 현재도 많은 JVM이 사용되고 있다.

ex) Oracle 의 핫스팟 , IBM의 Open J9 등등 ..

JVM 동작과정

앞서 JVM이 대략 무엇인지 알아보았으면 지금부터는 구체적인 동작과정을 알아볼 것이다.

JVM 구조

전체적인 동작 방식

JVM의 종류에 따라 상세한 방식은 살짝 다를 수 있지만, 전반적으로 다음과 같은 과정을 거친다.

1. 자바 코드를 바이트 코드로 컴파일한다.
2. 컴파일 된 바이트 코드를 클래스 로더에 전달한다.
3. 해당 클래스가 필요할 때 클래스 로더가 런타임 데이터 영역에 전달한다.
4. 실행 엔진이 해당 클래스 메소드를 실행 시킨다.

클래스 로더

클래스 로더의 구조

• 부트스트랩 클래스 로더
  • JVM을 구동시키기 위한 필수 라이브러리들을 탑재하고 있다.
  • 가장 초기에 실행되며 , 운영체제에 맞는 네이티브 코드로 쓰여있다.

• 익스텐션 클래스 로더
  • 자바 클래스의 핵심 라이브러리들을 탑재한다.

• 시스템 클래스 로더(Application ClassLoader)
  • 개발자들이 작성한 클래스 파일들을 탑재한다.
  • 이것을 상속하여 사용자 정의 클래스 로더를 구현할 수 있다.

요청이 들어왔을 때 모든 클래스 로더에 해당 클래스가 없을 시 ,

ClassNotFoundException 예외를 반환한다.

클래스를 로드하는 과정

클래스 어떻게 어떻게 클래스를 로드하는 지 간단하게 알아보자

• 로드
  • 클래스를 파일에서 가져와서 JVM 메모리에 할당한다.

• 링크
  • 검증(Verifying)
    • 클래스 파일이 유효한지를 검증한다.
    • 자바 명세 , JVM 명세를 잘 지켰는 지 확인하며 만약 테스트를 통과 못하였을 시에 VerifyError를 발생시킨다.
  • 준비(Preparing)
    • 클래스 및 인터페이스에 필요한 static field의 메모리를 할당하고 이를 기본값으로 초기화 한다.
  • 분석(Resolving):
    • constant pool 내에 있는 모든 **심볼릭 참조 값들을 메모리 주소(다이렉트)**로 변환시킨다.

• 초기화
  • 준비과정에서 기본값으로 초기화 시켜줬던 static filed들을 코드에 작성해줬던 초기값으로 변경해준다.

이 과정까지 마쳤으면 JVM에서 클래스 파일을 구동시킬 준비가 끝나게 된다.

클래스 로더의 특징

• 위임 모델
  • 클래스 로더는 계층 구조를 바탕으로 클래스 로더끼리 로드를 위임하는 구조로 동작한다.
  • 요청이 들어오면 상위 클래스로 요청을 위임해가면서 해당 클래스를 찾는데, 모든 클래스 로더에 없으면 클래스 패스에서 찾아보고 거기에도 없으면 예외를 반환한다.
  • 클래스 로더끼리 부모-자식 관계를 이루어 계층 구조로 생성되며 최상위 클래스 로더는 부트스트랩 클래스 로더이다.

• 가시성(visibility) 제한
  • 예를 들어서 어플리케이션 클래스 로더는 부트스트랩 로더의 클래스를 볼 수 있지만 , 그 반대는 안된다. (계층 구조)
  • 하위 클래스 로더는 상위 클래스 로더의 클래스를 찾을 수 있지만, 상위 클래스 로더는 하위 클래스 로더의 클래스를 찾을 수 없다.

• 언로드 불가
  • 클래스 로더는 클래스를 로드할 수는 있지만 언로드할 수는 없다. 언로드 대신, 현재 클래스 로더를 삭제하고 아예 새로운 클래스 로더를 생성하는 방법을 사용할 수 있다.

• 유일성
  • 하위 클래스 로더는 상위 클래스 로더가 로딩한 클래스를 다시 로딩하지 않음으로써 효율적으로 로딩이 가능하다

런타임 데이터 영역

런타임 데이터 영역은 JVM이 OS 할당 받는 메모리 영역이다.

크게 6가지의 영역이 있는데 , 공통으로 접근 가능 한것과 공유하지 않는 것을 구분 지어 알아보자

공유하지 않는 것

쓰레드 내에 있는 것들은 서로 접근 할 수 없다.

1. JVM 스택
   • 메서드가 하나씩 수행될 때마다 스택 프레임이 하나씩 쌓이게 된다.
   • 스택 프레임에는 지역 변수 배열이나 피연산자 스택 등 여러가지를 가지고 있다.
   예시 코드를 보면서 지역 변수 배열과 스택 기반 연산이 어떻게 이루어지는 지 알아보자

int num = 1; // 스택 프레임에 쌓임 
int sum = num + 5; // 스택 프레임에 쌓임

이런 간단한 코드를 수행할 때 JVM 스택 내에서는 어떤 일이 일어날까?

일단 위에서 말한 대로 스택 프레임에 메소드가 쌓이게 될 것 이다.

그 다음 지역 변수 배열에 파라미터 , 변수들이 저장이 되는 데 다음과 같이 저장된다.

다시 바이트 코드를 보자

L0
    LINENUMBER 15 L0
    ICONST_1 // 스택에 정수값 1을 올린다.
    ISTORE 1 // 스택에 있는 정수값을 꺼내서 1번 인덱스에 저장
   L1
    LINENUMBER 16 L1
    ILOAD 1 // 1번 인덱스의 값을 스택에 올려라
    ICONST_5 // 스택에 정수값 5를 올린다.
    IADD // 스택 상단 두 개의 값을 더한다.
    ISTORE 2 // 2번 인덱스에 저장한다.

이렇게 해서 값을 반환하고 연산을 마치게 된다.

2.PC 레지스터

• 현재 JVM 명령의 주소를 가지는 쓰레드 공유의 레지스터이다.
• 쓰레드가 시작될 때 생성된다.

3.네이티브 메서드 스택

• JNI 라는 것은 통해 자바가 아닌 c나 c++을 통해 클래스를 작성하였을 시 이를 수행하기 위한 스택이다.

공유하는 것

1. 힙
   • 인스턴스 혹은 객체를 저장한다.
   • 메모리를 정리하는 가비지 컬렉터의 작업이 주로 이루어진다.
2. 메서드 영역
   • 클래스 로더로 부터 불러온 클래스의 바이트 코드 정보들을 저장한다.

실행 엔진

실행 엔진에서 비로소 기계어로의 번역을 시작한다.

이때 두가지 방법이 쓰이는 데 인터프리터와 JIT 방식이다.

인터프리터

• 바이트 코드 명령어를 하나씩 읽어서 수행한다.
• 해석은 빠르지만 실행은 느리다는 단점이 있다.
• 바이트 코드는 기본적으로 인터프리터로 동작한다.

JIT(Just-In-Time)

• 바이트 코드 전체를 네이티브 코드로 번역한다.
• 이후 인터프리팅을 하지 않고 네이티브 코드로 직접 실행하며 한번 컴파일 된 코드는 캐시에 저장된다.
• 하지만 처음 컴파일 과정이 오래 걸리므로 한번만 쓰는 메소드는 JIT 사용이 적합하지 않다.

참고자료

JVM에 관하여 - Part 2, ClassLoader

JVM. 클래스로더 서브시스템(Class Loader Subsystem)

https://www.youtube.com/watch?v=6reapO0gLPs&t=399s

프로그래머스 백엔드 데브코스에서 진행한 Tech Log 활동 목적으로 제작되었습니다.

1. String 클래스의 equals & hashcode

소프트웨어 세계에서는 문자열도 이상한 방식으로 관리한다.

바로 동등성을 보장해주기 위함인데,

이때 앞에서 말한 equals 메소드와 HashCode 메소드를 재정의해서 사용한다.

이를 재정의하지 않는 클래스를 처음부터 만들어가면서 equals 와 HashCode 에 대해 알아보자

본문에서는 String을 모방한 String_test 객체를 만들어 볼것이며 , 각각의 결과값들을 맞춰나갈 것이다.

equals 비교

먼저 객체의 동등성을 비교하기 위해 equals의 값을 비교해보자

String string1 = new String("hi");
String string2 = new String("hi");

System.out.println("String 객체 hashcode 비교 결과 : "+(string1.equals(string2)));

String_test string1_test = new String_test("hi");
String_test string2_test = new String_test("hi");

System.out.println("String 객체 hashcode 비교 결과 : "+(string1_test.equals(string2_test)));

같은 값을 가지는  클래스끼리 비교하였지만

String 객체는 equals 의 true이고 ,

String_test는 equals 의 값이 false 가 나왔다.

hashcode 비교

다음은 객체의 hashcode 값을 비교해보자

String string1 = new String("hi");
String string2 = new String("hi");

System.out.println("String 객체 hashcode 비교 결과 : "+(string1.hashCode() == string2.hashCode()));

String_test string1_test = new String_test("hi");
String_test string2_test = new String_test("hi");

System.out.println("String_test 객체 hashcode 비교 결과 : "+(string1_test.hashCode() == string2_test.hashCode()));

해쉬코드 비교 결과값도 String 객체와 다르게 나오는 것을 볼 수 있다.

🧐 왜 이런 결과가 나왔을까?

정답은 equals 와 hashcode 의 오버라이딩에 있다.

이 둘을 재정의 하기 전에 각각 원래 무슨 역할을 하는 메소드인지 부터 알아보자

2. equals 란 ?

equals 메소드는 2개의 객체가 동등한 지 검사하기 위해 사용되는 메소드이다.

예를 들어,

String string1 = new String("hi");
String string2 = new String("hi");

System.out.println(string1 == string2); // false
System.out.println(string1.equals(string2)); // true

다음과 같이 String 클래스를 생성하여 비교하는 경우 "==" 는 동일성을 비교하기 때문에 false 를 출력하지만 , equals 메소드는 동등성을 비교하기 때문에 true를 출력한다.

*동등성과 동일성의 차이는 뭘까?

동등성은 대상의 대상의 내용을 비교하고

동일성은 주소값을 비교하여 같은 객체인 지를 비교한다.

Object 클래스의 equals 코드를 살펴보자

public boolean equals(Object obj) {
			return this == obj;
    }

근데 정작 Object의 코드를 보면 동등성을 비교해주지 않는다 .(주소값을 비교한다.)

그런데 왜 String 에서는 문자열의 동등성을 비교할 수 있는 걸까?

자바 공식문서에 보면 String의 equals 메소드는 다음과 같이 equals 메소드를 재정의 한다고 나와있다.

그렇기에 우리는 equals 메소드를 동등성 비교에 사용할 수 있는 것이다 !

그러면 String_test 메소드에도 이런 방식으로 equals를 재정의 하면 동등성 비교가 되지 않을까 ?

우리가 만든 Spring_test 클래스에도 equals 를 재정의 해주었다.

class String_test {
    String string;

    public String_test(String string) {
        this.string = string;
    }

    @Override
    public boolean equals(Object o) {
        if (this == o) return true;
        if (o == null || getClass() != o.getClass()) return false;
        String_test that = (String_test) o;
        return Objects.equals(string, that.string);
    }
}

그리고 결과값도 의도한 대로 true 가 나왔다 !

3. hashCode란 ?

hashCode 메소드는 객체의 해시코드를 리턴한다.

*객체의 해시코드란?

객체의 주소값을 변환하여 생성한 고유의 해시값이다.

하지만 기존 방식으로 해시코드를 생성한다면 다른 객체에 대해서 다른 문자열이라도 다른 해시코드를 받을 것이다.

→ 이렇게 된다면 동등성을 보장할 수 없다 !

따라서 String 클래스는 hashCode 역시 재정의해서 사용한다.

자바 공식 문서를 보면 문자열의 문자들을 한 글자씩 가져와서 변환한다는 것을 알 수 있다.

그렇기에 다른 주소값의 객체라도 문자열이 같으면 같은 hashcode 가 나오는 것이다.

따라서 우리가 만든 Spring_test 클래스도 hashCode 를 재정의 해보았다.

class String_test {
    String string;

    public String_test(String string) {
        this.string = string;
    }

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

String 객체처럼 Spring_test 객체도 같은 값이 나옴을 알 수 있다.

Hash 와 Hash 테이블의 관계

hashCode 메소드를 이용해서 해시코드 값을 받는 다는 것을 알게되었다.

이렇게 얻게 된 해시코드는 어디에 사용되는 걸까?

hashCode 와 equals 의 관계를 알기 전 우리는 해시테이블이라는 자료구조에 대해 알아볼 것이다.

🧐 자료구조? 그게 뭔가요?

도서관에는 정말 많은 책들이 있다.

만약 자기가 사서 관리를 맡았는 데 이 많은 책들 중에서 특정 책을 찾거나 정리해야 한다고 생각하면 여간 막막한 일이 아닐 것이다.

다행히 이런 일들을 우리가 처음 겪은 게 아니고 옛날부터 많은 기술자들이 고안한 끝에 데이터를 쉽게 찾고 꺼내올 수 있는 규칙과 틀을 미리 만들어 두었다.

이것들 중에 하나가 우리가 알아볼 해시 테이블이다.

해시테이블이란?

데이터를 key , value 로 저장하는 형태를 말한다.

보통 도서관에서는 도서 관리 번호를 지정하고 , 그 번호를 찾아보면 해당 책을 발견할 수 있다.

이것도 현실 세계에서의 key , value 형태라고 부를 수 있을 것이다.

해시 테이블의 원리

다시 소프트웨어로 돌아와서 이러한 형태의 해시 테이블이 어떻게 만들어지는 지 알아보자

도서관의 책들을 key , value 형태로 저장하려고 한다.

이때 key는 책 이름 , value는 가격으로 해주었다.

그 결과, 가장 오른쪽에 있는 Bucket에는 해쉬 연산을 통해 나온 인덱스와 value(책 가격) 이 담긴다.

이런식으로 저장을 하게 되면 데이터를 찾을 때 Hash 연산을 한번만 수행하면 되므로 매우 빠르게 데이터를 조회할 수 있다.

→ 이런 경우 시간 복잡도는 O(1) 이 된다 !

🧐 그런데 만약 서로 다른 책들끼리 같은 해쉬 연산 결과가 나와서 같은 인덱스에 저장된다면 어떻게 될까 ?

이 문제를 해결하기 위한 대표적인 방법 두가지를 소개해보려고 한다.

Separate Chaining 기법

해쉬테이블에서는 하나의 인덱스에 여러 개의 버킷을 연결시키는 것으로 해결할 수 있다.

다시 그림을 보자

분명 다른 책인데, 같은 인덱스에 저장이 되었다.

즉 해시 충돌이 발생하니까 새로운 값을 기존 값과 연결시킨 거라고 볼 수 있다.

하지만 이렇게 하면 버킷에 하나의 데이터만 저장하는 것 보다 효율이 안좋아진다.

기존엔 해시 함수 결과에 따라 해당 인덱스만 찾아가면 됐었는데 , 이제는 그 안에서 한번 더 탐색을 해야하기 때문이다.

최악의 경우 모든 데이터를 뒤져봐야 할 수도 있다.

→ 시간복잡도는 평균적으로 O(n/m) 최악의 경우 O(n) 을 가지게 될 수 있다.

(해시 테이블의 저장소(Bucket)의 길이를 ‘m’, 키(key)의 수를 ‘n’)

이를 보완하기 위해 자바8 이상부터는 하나의 해시 버킷에 할당 된 데이터가 8개 이상이 되면 연결 리스트에서 트리로 구조를 변경한다.

→ 이럴 경우 평균 적인 시간 복잡도는 O(log(n/m)) 이 된다.

Open addressing 기법 (개방 주소법)

개방 주소법은 해시값의 인덱스에 데이터가 있을 시에 다른 인덱스를 탐색하여 데이터를 저장하는 방법이다.

같은 인덱스에 여러 개의 데이터를 저장하는 방법과는 상반된 방법이다 !

해시 충돌이 발생 했을 시에 어느 인덱스에 데이터를 저장할 것인지를 결정하는 방법은 총 3가지가 있다.

선형 탐색 (linear probing)

충돌이 일어났을 때, 한칸 또는 n칸씩 다음 인덱스가 비어있는지 확인해본다.

제곱 탐색 (quadratic probing)

1의 제곱 , 2의 제곱 … 만큼 인덱스를 이동해가면서 비어있는지 확인해본다.

이중 해시 (Double Hash)

위에 두 방법을 통해서 어느 정도 충돌을 해결할 순 있다.

하지만 해쉬값이 같을 경우 빈 슬롯을 찾아 접근하는 위치가 동일하므로

접근 슬롯을 중심으로 데이터가 한 곳에 집중되어 있는 현상이 발생할 수 있다.

이 상황을 피하기 위해 나온 방법이 이중 해시이다.

말 그대로 해시 함수를 두 번 돌린 것이다.

예를 들어,

1차 해시는 키를 삽입하여 데이터의 해시 인덱스를 정한다.

2차 해시는 충돌이 발생하였을 시에 몇 칸 뒤로 인덱스를 이동할 지 정한다.

이처럼 이중 해시를 사용하면 1차 해시값이 같더라도 2차 해시값은 달라지므로,

데이터의 군집 문제를 어느정도 해결할 수 있다.

개방 주소법의 경우에도 해당 인덱스에 충돌이 발생했었다면 다음 인덱스를 찾아가면서 탐색을 해야하므로 최악의 경우 O(n) 의 시간 복잡도를 가질 수 있다.

🧐 근데 데이터가 점점 많아진다면 어떻게 될까 ?

아마 해쉬 충돌은 빈번해지며 효율은 더욱 나빠질 것이다.

(참고로 자바에서 제공하는 기본 버킷 사이즈는 16이다)

이 상황에 대해 묘사한 재밌는 이론이 있다.

비둘기 집 원리

만약 9개의 비둘기 집이 있는 데 10마리 이상의 비둘기가 들어가려고 한다면?

어쩔 수 없이 2마리 이상의 비둘기가 함께 지내야 할 것이다.

이 상황은 무한한(비둘기) 입력에 대해 유한한(비둘기 집) 출력만이 존재하기 때문에 나타난 현상이라고 할 수 있다.

소프트웨어에서도 마찬가지다.

key값은 무한하지만 버킷 과 해쉬값 은 유한하다.

이 경우 해쉬테이블은 Dynamic Resizing 을 통해서 버킷의 사이즈를 두 배씩 늘려준다.

이때 늘릴 수 있는 최대 길이는 2^30 이다 !

이제 HashCode의 역할과 해시 값을 이용한 해시 테이블도 알아보았으니

이쯤에서 equals and hashcode에 대해 알아보자

4. equals 와 hashcode 을 왜 같이 재정의 해줘야할까 ?

위에서 보았듯이 일반적으로 equals 와 hashcode 는 같이 오버라이딩 해주고 있다.

만약 equals만 오버라이딩 해준다면 여러 문제가 발생할 수 있는데 , 대표적으로 해쉬 자료구조를 사용할 때이다.

중복을 허용하지 않는 set를 예로 들어보자

같은 값의 객체를 넣어준다면 하나만 들어가야 정상일 것이다.

equals만 오버라이딩 하였을 경우

class Test {
    String key;

		public Test(String key) {
        this.key = key;
    }
		
    @Override
    public boolean equals(Object o) {
        if (this == o) return true;
        if (o == null || getClass() != o.getClass()) return false;
        Test test = (Test) o;
        return Objects.equals(key, test.key);
    }    
}

Set<Test> set = new HashSet<>();
        
set.add(new Test("hi"));
set.add(new Test("hi"));

System.out.println(set.size()); // 결과 2

같은 값을 가지는 객체를 넣어줬는데 두개가 들어가는 결과가 나왔다.

이는 Hash 테이블에서 같은 값을 가짐에도 다른 객체로 인식하였다는 것이다.

hashCode 만 오버라이딩 하였을 경우

class Test {
    String key;

    public Test(String key) {
        this.key = key;
    }

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

Set<Test> set = new HashSet<>();
        
set.add(new Test("hi"));
set.add(new Test("hi"));

System.out.println(set.size()); // 결과 2

마찬가지로 같은 값을 가지는 객체를 넣어줬는데 두개가 들어가는 결과가 나왔다.

이 경우도 같은 값을 가짐에도 다른 객체로 인식하였다는 것이다.

🧐 왜 Equals와 HashCode 둘 중 하나만 재정의 하였을 시에 오류가 나는 걸까 ?

이 이유를 알기 위해 해쉬 자료구조의 동작 원리를 순서대로 알아보자

해쉬 맵의 동작 구조

해쉬 자료구조에서 객체가 동등한 지를 비교할 땐 다음 과정을 거친다.

1. 해쉬코드의 값을 비교한다.
2. 해쉬코드의 값이 같다면 equals의 값을 비교한다.
3. 위 두개의 값이 같다면 동등 객체라고 판단한다.

따라서 ,

equals만 재정의 하였을 경우 해쉬코드가 다르게 나왔기 때문이고

hashCode 만 재정의 하였을 경우 equals의 반환값이 false 였기 때문에 다른 객체로 보았던 것이다.

이처럼 둘을 동시에 재정의 해주지 않으면, Hash 자료구조를 사용하면서 예상치 못한 결과를 불어올 수 있다.

4. equals & hashCode 규약

1. equals() 비교에 사용되는 정보가 변경되지 않았다면, 애플리케이션이 실행되는 동안 그 객체의 hashcode()는 항상 같은 값을 반환해야한다.
2. equals()로 비교했을 때 같다고 판단했다면, 두 객체의 hashCode는 같은 값을 반환해야 한다.
3. equals()가 두 객체를 다르다고 판단한 경우 꼭 hashCode가 다를 필요는 없다.
4. 다른 값을 반환하는 게 좋다.

5. 결론

해시코드와 equals의 차이에 대해 알아보고 , 이 둘을 왜 같이 재정의 해줘야하는지에 대해서도 알아보았다.

만약 이 둘을 같이 재정의 해주지 않는다면 위처럼 해쉬 자료구조를 이용할 때 예상치 못한 결과를 가져온다.

동등성을 보장해주지 못하기 때문에 다른 객체로 인식이 되기 때문이다.

따라서 equals와 hashCode 를 같이 재정의 하도록 하자 !

6.참고 자료

Java HashMap은 어떻게 동작하는가?

equals와 hashCode는 왜 같이 재정의해야 할까?

Hashtable의 이해와 구현 #1

equals와 hashCode는 왜 같이 재정의해야 할까?

[데이터 구조] Hashtable 충돌(collisoion)을 해결하는 방법에 대해서 이해가 필요하다. (open addressing, separate chaining) +설명영상