[Java] 가비지 컬렉터(Garbage Collector)

bien·2025년 1월 22일

JVM Java

Java_Spring_Backend

목록 보기

5/10

Reference

☕ 가비지 컬렉션 동작 원리 & GC 종류 💯 총정리
출처: https://inpa.tistory.com/entry/JAVA-☕-가비지-컬렉션GC-동작-원리-알고리즘-💯-총정리 [Inpa Dev 👨‍💻:티스토리]

Garbage Collector

가비지 컬렉션(GC, Garbage Collection)
- 자바의 메모리 관리 방법
- JVM(자바 가상 머신)의 Heap 영역에 동적으로 할당했던 메모리 중 필요없게 된 메모리 객체(garbage)를 모아 주기적으로 제거하는 프로세스
- C/C++은 프로그래머가 수동으로 메모리 할당, 해제를 일일이 해줌
  - Java는 GC가 메모리 관리를 대행하므로, 개발자 입장에서 메모리 관리, 누수 문제를 고려하지 않고 개발에만 집중할 수 있다.

객체 제거 기능

for (int i = 0; i < 10000; i++) {
  NewObject obj = new NewObject();  
  obj.doSomething();
}

위의 코드에서, 루프 내부에서 10000 개의 NewObject가 생성해 Heap 영역을 차지한다.
해당 객체들은 루프 밖에선 더 이상 사용할 일이 없으나 지속적으로 메모리를 점유하고 있게되고, 다른 코드를 실행하기 위한 메모리 자원이 줄어들게된다.

그러나 우린 이에 대해 고려하지않고 구현 코드를 이어나가는데, 이는 가비지 컬렉션(GC)이 버려지는 객체들을 비워주어 한정된 메모리의 효율적인 사용을 돕기 때문이다.

타언어의 GC

자바 이외에도 많은 프로그래밍 언어에서 가비지 컬렉션이 기본으로 내장되어 있다.
- 파이썬, 자바스크립트, Go 언어 등
브라우저도 자체적으로 구현된 가비지 컬렉션이 있어 별다른 메모리 관리 없이 웹페이지를 만들 수 있다.

한계점

(자동으로 처리함에도 불구하고) 메모리가 언제 해제되는지 정확하게 알 수 없어 제어가 힘들다.
가비지 컬렉션(GC) 동작 중에는 다른 동작을 멈추기 때문에 오버헤드가 발생한다.
- 이를 전문적인 용어로 Stop-The-World라고 한다.
- 따라서, GC가 너무 빈번하게 실행되면 소프트웨어 성능이 하락할 수 있다.
  - ex) 익스프롤러: GC가 너무 자주 실행되어 성능문제를 일으키는 것으로 악명이 높았음
  - 실시간성이 강조되는 프로그램은 가비지 컬렉터(GC)에게 메모리를 맞기는 것이 적절하지 않을 수 있음
  - 애플리케이션의 사용성은 유지하고, 효율적으로 GC를 실행하는 최적화 작업이 개발자의 숙제가 될 수 있다.

STW (Stop The World)

GC를 수행하기 위해 JVM이 프로그램 실행을 멈추는 현상을 의미
GC가 동작하는 동안 GC관련 Thread를 제외한 모든 Thread는 멈추게되어 서비스 이용에 차질이 생길 수 있다.
- 따라서 이 시간을 최소화 시키는 것이 쟁점.

가비지 컬렉션 대상

가비지 컬렉션(Garbage Collection)은 어떤 Object를 Garbage로 판단해서 스스로 지워버릴까?

가비지 컬렉션은 도달성, 도달능력(Reachability)이라는 개념을 통해 garbage 여부를 판단한다.
객체에 레퍼런스가 있다면 Reachable로 구분되고, 객체에 유효한 레퍼런스가 없으면 Unreachable로 구분해버리고 수거해버린다.

도달성, 도달능력(Reachability)
1. Reachable: 객체가 참조되고 있는 상태
2. Unreachable: 객체가 참조되고 있지 않은 상태 (GC의 대상이 됨)

JVM 메모리에서 객체들은 실질적으로 Heap 영역에서 생성되고 Method Area나 Stack Area에서는 Heap Area에 생성된 객체의 주소만 참조하는 형식으로 구성된다.

하지만 이렇게 생성된 Heap Area의 객체들이 메서드가 끝나는 등의 특정 이벤트들로 인하여 Heap Area 객체의 메모리 주소를 가지고 있는 참조 변수가 삭제되는 현상이 발생하면, 위의 그림에서의 빨간색 객체와 같이 Heap 영역에서 어디서든 참조하고 있지 않은 객체(Unreachable)들이 발생하게 된다.

이러한 객체들을 주기적으로 가비지 컬렉터가 제거해주는 것이다.

가비지 컬렉션 청소방식

Mark And Sweep

Mark-Sweep: 다양한 GC에서 사용되는 객체를 솎아내는 내부 알고리즘
가비지 컬렉션이 동작하는 아주 기초적인 청소 과정

가비지 컬렉션이 될 대상 객체를 식별(Mark)하고 제거(Sweep)하며 객체가 제거되어 파편화된 메모리 영역을 앞에서부터 채워나가는 작업(Compaction)을 수행하게 된다.

Mark 과정: 먼저 Root Space로부터 그래프 순회를 통해 연결된 객체들을 찾아내어 각각 어떤 객체를 참조하고 있는지 찾아서 마킹한다.
Sweep 과정: 참조하고 있지 않은 객체 즉 Unreachable 객체들을 Heap에서 제거한다.
Compact 과정: Sweep 후에 분산된 객체들을 Heap의 시작 주소로 모아 메모리가 할당된 부분과 그렇지 않은 부분으로 압축한다. (가비지 컬렉터 종류에 따라 하지 않는 경우도 있음)

GC의 Root Space

Mark And Sweep 방식은 루트로부터 해당 객체에 접근이 가능한지가 해제의 기준이 된다.
JVM GC에서의 Root Space는 Heap 메모리 영역을 참조하는 method area, static 변수, static, native method stack이 되게 된다.

Heap 메모리 구조

JVM의 힙(Heap) 영역은 동적으로 레퍼런스 데이터가 저장되는 공간으로, 가비지 컬렉션의 대상이 되는 공간이다.

설계 근거: 약한 세대 가설(Weak Generational Hypothesis)

Heap 영역 설계의 2가지 전제(Weak Generational Hypothesis) 조건
1. 대부분의 객체는 생성 직후 빠르게 접근 불가능한 상태(Unreachable)가 된다.
2. 오래된 객체에서 새로운 객체로의 참조는 아주 적게 존재한다.

즉, 객체는 대부분 일회성이며, 메모리에 오랫동안 남아있는 경우는 드물다는 것이다.

가설의 영향

가설을 바탕으로 JVM은 다음과 같은 메모리 관리 전략을 채택했다:

메모리 구조 설계
- Heap 영역을 Young 영역과 Old 영역으로 분리
  - 새로운 객체는 Young 영역에 할당
  - 오래 살아남은 객체는 Old 영역으로 이동
GC 최적화
- Young 영역에 대해 더 빈번한 GC 수행(Minor GC)
- Old 영역은 상대적으로 덜 빈번한 GC 수행
  - 메모리 수짐 효율성 향상 및 GC 부하 감소

Heap의 영역

그림에서 Old 영역이 Young 영역보다 크게 할당되는 이유는 Young 영역의 수명이 짧은 객체들은 큰 공간을 필요로 하지 않으며 큰 객체들은 Young 영역이 아니라 바로 Old 영역에 할당되기 때문이다.

1. Young 영역 (Young Generation)

새롭게 생성된 객체가 할당(Allocation)되는 영역
대부분의 객체가 금방 Unreachable 상태가 되기 때문에, 많은 객체가 Young 영역에 생성되었다가 사라진다.
Young 영역에 대한 가비지 컬렉션(Garbage Collection)을 Minor GC라고 부른다.

더욱 효율적인 GC를 위해 Young 영역을 3가지 영역(Eden, survivor0, survivor1)으로 나눈다.

Eden

new를 통해 새로 생성된 객체가 위치
장기적인 쓰레기 수집 후 살아남은 객체들은 Survivor 영역으로 보냄

Survivor 0 / Survivor 1

최소 1번의 GC 이상 살아남은 객체가 존재하는 영역
Survivor 영역에는 특별한 규칙이 있는데, Survivor 0 또는 Survivor 1 둘 중 하나는 꼭 비어있어야 하는 것이다.

2. Old 영역 (Old Generation)

Young 영역에서 Reachable 상태를 유지하여 살아남은 객체가 복사되는 영역
Young 영역보다 크게 할당되며, 영역의 크기가 큰 만큼 가비지는 적게 발상한다.
Old 영역에 대한 가비지 컬렉션(Garbage Collection)을 Major GC 또는 Full GC라고 부른다.

[ Java8의 Permanaet ]

Permanent는 영구적인 세대를 의미하고, 생성된 객체들의 정보의 주소값이 저장된 공간이다.

클래스 로더에 의해 load되는 Class, Method 등에 대한 Meta 정보가 저장되는 영역이고 JVM에 의해 사용된다.

Java 7까지는 힙 영역에 존재했지만 Java8 이후에는 Native Method Stack에 편입되게 된다.

Minor / Major GC

Minor GC

Young Generation의 공간은 Old Generation에 비해 상대적으로 작기 때문에 메모리 상의 객체를 찾아 제거하는데 적은 시간이 걸린다. (적은 공간에서 데이터를 찾으므로)
- 이 때문에 Young Generation 영역에서 발생되는 GC를 Minor GC라고 부른다.

Minor GC의 동작 절차

처음 생성된 객체는 Young Generation 영역의 일부인 Eden 영역에 위치
객체가 계속 생성되어 Eden 영역이 꽉차게 되고 Minor GC가 실행
Mark 동작을 통해 reachable 객체를 탐색
Eden 영역에서 살아남은 객체는 1개의 Survivor 영역으로 이동
Eden 영역에서 사용되지 않는 객체(unreachable)의 메모리를 해제(sweep)
살아남은 모든 객체들은 age 값이 1씩 증가
또 다시 Eden 영역에 신규 객체들로 가득 차게 되면 다시 한번 minor GC 발생하고 mark한다.
marking한 객체들을 비어있는 Survival 1으로 이동하고 sweep
다시 살아남은 모든 객체들은 age가 1씩 증가
이러한 과정을 반복

age 값이란?

Survivor 영역에서 객체가 살아남은 횟수를 의미하는 값이며, Object Header에 기록된다.
만일 age 값이 임계점에 다다르면 Promotion(Old 영역으로 이동) 여부를 결정한다.
JVM 중 가장 일반적인 HotSpot JVM의 경우 이 age의 기본 임계값은 31이다.
객체 헤더에 age를 기록하는 부분이 6bit로 되어있기 때문이다.

또한 Survivor 영역의 제한 조건으로 Survivor 영역 중 반드시 1개는 사용되어야 하고, 나머지는 비어있어야 한다.
만약 두 Survivor 영역에 모두 데이터가 존재하거나, 모두 사용량이 0이라면 현재 시스템이 정상적인 상황이 아니라는 반증이 된다.

Survivor Space Switching

첫 번재 Minor GC
- Eden -> Survivor 0으로 살아남은 객체 이동
- Survivor 1은 비어있음
두 번째 Minor GC
- Eden의 살아남은 객체 + Survivor 0의 살아남은 객체 → Survivor 1로 이동
- Survivor 0은 비어있게 됨
세 번째 Minor GC
- Eden의 살아남은 객체 + Survivor 1의 살아남은 객체 → Survivor 0으로 이동
- Survivor 1은 비어있게 됨

항상 하나의 Survivor 영역은 반드시 비어있어야 한다.
객체들이 Survivor 영역을 왔다갔다 할 때마다 age가 1씩 증가한다.
age가 임계값(기본값 31)에 도달하면 Old Generation으로 승격(Promotion)된다.

Major GC (Full GC)

Old Generation의 객체들은 거슬러 올라가면 처음에는 Young Generation에 의해 시작되었으나, GC 과정 중에 제거되지 않은 경우 age의 임계값이 차게되어 이동된 녀석들이다.
그리고 Major GC는 객체들이 계속 Promotion되어 Old 영역의 메모리가 부족해지면 발생하게 된다.

Major GC의 동작과정

객체의 age가 임계값에 도달하게되면 객체들이 Old Generation으로 이동한다.
- 이를 promotion이라고 부른다.
위의 과정이 반복되어 Old Generation 영역의 공간(메모리)가 부족하게 되면 Major GC가 발생한다.

Major GC의 성능 영향

Old Generation은 YoungGeneration에 비해 상대적으로 큰 공간을 가지고 있어, 이 공간에서 메모리 상의 객체 제거에 많은 시간이 걸리게 된다.

Young 영역은 GC의 소요시간이 0.5 ~ 1초 사이 끝난다. 따라서 Minor GC는 애플리케이션에 크게 영향을 주지 않는다.
반면, Old 영역의 Major GC는 일반적으로 Minor GC보다 시간이 오래걸리며, 10배 이상의 시간을 사용한다.

따라서, Stop-The-World 문제가 발생할 수 있다.
Major GC가 일어나면 Thread가 멈추고 Mark and Sweep 작업을 수행해야 해 CPU에 부하를 주므로, 멈추거나 버벅이는 현상이 일어나기 때문이다.

이를 해결하기 위해 자바 개발진은 끊임없이 가비지 컬렉션 알고리즘을 발전시켜왔다.

GC 알고리즘

Serial GC

서버의 CPU 코어가 1개일 때 사용하기 위해 개발된 가장 단순한 GC
GC를 처리하는 쓰레드가 1개(싱글 쓰레드)이어서 가장 stop-the-world 시간이 길다.
Minor GC에는 Mark-Sweep을 사용하고, Major GC에는 Mark-Sweep-Compact를 사용한다.
보통 실무에서 사용하는 경우는 없다.
- 디바이스 성능이 안좋아서 CPU 코어가 1개인 경우에만 사용

Parallel GC

Java8의 디폴트 GC
Serial GC와 기본적인 알고리즘은 같지만, Young 영역의 Minor GC를 멀티쓰레드로 수행 (Old 영역은 여전히 싱글쓰레드)
Serial GC에 비해 stop-the-world 시간 감소

Parallel Old GC (Parallel Compacting Collector)

Parallel GC를 개선한 버전
Young 영역 뿐만 아니라, Old 영역에서도 멀티쓰레드로 GC 수행
새로운 가비지 컬렉션 청소 방식인 Mark-Summary-Compact 방식을 이용 (Old 영역도 멀티 쓰레드로 처리)

CMS GC (Concurrent Mark Sweep)

어플리케이션의 쓰레드와 GC 쓰레드가 동시에 실행되어 stop-the-world 시간을 최대한 줄이기 위해 고안된 GC
- 단, GC 과정이 매우 복잡해짐
- GC 대상을 파악하는 과정이 복잡한 여러 단계로 수행되기 때문에 다른 GC 대비 CPU 사용량이 높다.
- 메모리 파편화 문제 발생
CMS GC는 Java 9 버전부터 deprecated 되었고 결국 Java14에서는 사용이 중지

G1GC (Garbage First)

CMS GC를 대체하기 위해 jdk 7 버전에서 최초로 release된 GC
Java 9+ 버전의 디폴트 GC로 지정
4GB 이상의 힙 메모리, Stop the World 시간이 0.5초 정도 필요한 상황에 사용 (Heap이 너무 작을경우 미사용 권장)
기존의 GC 알고리즘에서는 Heap 영역을 물리적으로 고정된 Young/Old 영억으로 나누어 사용하였지만, G1 gc는 아예 이러한 개념을 뒤엎는 Region이라는 개념을 새로 도입하여 사용.
- 전체 Heap 영역을 Region이라는 영역으로 체스같이 분할하여 상황에 따라 Eden, Survivor, Old 등 역할을 고정이 아닌 동적으로 부여
Garbage로 가득찬 영역을 빠르게 회수하여 빈 공간을 확보하므로, 결국 GC 빈도가 줄어드는 효과를 얻게 되는 원리

Shenandoah GC

Java12에 release
레드 햇에서 개발한 GC
기존 CMS가 가진 단편화, G1이 가진 pause의 이슈를 해결
강력한 Concurrency와 가벼운 GC 로직으로 heap 사이즈에 영향을 받지 않고 일정한 pause 시간이 소요가 특징

ZGC (Z Garbage Collector)

Java15에 release
대량의 메모리 (8MB ~ 16TB)를 low-latency로 잘 처리하기 위해 디자인 된 GC
G1의 Region처럼, ZGC는 ZPage라는 영역을 사용하며, G1의 Region은 크기가 고정인데 비해, ZPage는 2mb 배수로 동적으로 운영됨 (큰 객체가 들어오면 2^ 로 영역을 구성해서 처리)
ZGC가 내새우는 최대 장점 중 하나는 힙 크기가 증가하더라도 stop-the-world의 시간이 절대 10ms를 넘지 않는다는 것

bien

Good Luck!

이전 포스트

[Java] JVM 메모리 구조

다음 포스트