가비지 컬렉션 동작 원리 & GC 종류
Garbage Collection(GC) 이란?
자바의 메모리 관리 방법 중 하나로 JVM (자바 가상 머신)의 Heap 영역에서
동적으로 할당했던 메모리 중 필요 없게 된 메모리 객체 (garbage)를 모아 주기적으로 제거
C / C++에는 GC 없어서 프로그래머가 수동으로 메모리 할당/해제 해줘야 함.
Java는 가비지 컬레터가 메모리 관리 대행해주기 때문에 Java 프로세스가 한정된 메모리를 효율적으로 사용할 수 있도록 해줌
개발자 입장에서 메모리 관리, 메모리 누수(Memory Leak) 문제에 대해 관리하지 않아도 됨
(python, javascript, go 등에도 gc 내장됨)
for (int i = 0; i < 10000; i++) {
NewObject obj = new NewObject();
obj.doSomething();
}
위의 코드에서 루프문에 의해 10000건의 객체 생성, but 루프가 끝나면 밖에서는 그 객체를 더이상 사용하지 않음
GC는 이처럼 한번 쓰고 버려지는 객체들을 주기적으로 비워줌으로써 한정된 메모리를 효율적으로 쓸 수 있게 해줌
GC의 단점
1. 메모리 해제 시점을 정확히 알 수 없어 제어가 힘들다
2. GC 동작 중에는 다른 동작을 멈추기 때문에 오버헤드 (STW, Stop-The-World)
- GC가 동작하는 동안 GC 관련 Thread 제외한 모든 Thread 정지
- 이 시간을 최소화 시키는 것이 쟁점
GC가 너무 자주 실행되면 소프트웨어 성능 하락
ex) 익스플로러는 GC를 너무 자주 실행시켜서 성능 문제
따라서, 실시간 성이 중요한 프로그램은 GC 사용하는 것 바람직하지 않음
GC 최적화 작업이 중요
가비지 컬렉션 대상
도달성, 도달능력에 따라 판단
객체에 레퍼런스가 있다면(참조되는 상태) Reachable, 레퍼런스가 없으면(참조되고 있지 않은 상태) Unreachable
Unreachable 한 객체는 참조의 대상이 됨
JVM 메모리에서는 Heap 영역에 객체를 생성하고, Stack에서는 이를 참조하는 변수를 둔다.
이때, Stack에서 참조하는 변수가 삭제되면, 위의 그림의 빨간색 객체와 같이 Unreachable 한 상태가 된다.
이러한 객체들을 가비지 컬렉터가 제거해 주는 것
가비지 컬렉션 청소 방식
Mark And Sweep
다양한 GC에서 사용되는 객체를 솎아내는 내부 알고리즘으로 GC가 동작하는 아주 기초적인 청소 과정
대상 객체를 식별(Mark)하고 제거(Sweep)하며
객체가 제거되어 파편화된 메모리 영역을 앞에서부터 채워나가는 작업(Compaction)을 수행
- Mark 과정 : 먼저 Root Space로부터 그래프 순회를 통해 연결된 객체들을 찾아내어 각각 어떤 객체를 참조하고 있는지 찾아서 마킹한다.
- Sweep 과정 : 참조하고 있지 않은 객체, 즉 Unreachable한 객체들을 Heap에서 제거한다.
- Compact 과정 : Sweep 후에 분산된 객체들을 Heap의 시작 주소로 모아 메모리가 할당된 부분과 그렇지 않은 부분으로 압축
GC의 Root Space
Mark And Sweep 방식은 루트로부터 해당 객체에 접근이 가능한지가 해제의 기준
JVM GC의 RootSpace는 Heap 메모리 영역을 참조하는 method area, static 변수, stack, native method stack
GC 동작 과정
Heap 메모리의 구조
JVM의 힙(Heap) 영역은 동적으로 레퍼런스 데이터가 저장되는 공간
가비지 컬렉션의 대상이 되는 공간
Heap 영역은 설계 시 2가지를 전제함
1. 대부분의 객체는 금방 접근 불가능한 상대(Unreachable)가 된다.
2. 오래된 객체에서 새로운 객체로의 참조는 아주 적게 존재한다. (young 삭제할 때, old가 참조하는지 mark 하지 않아도 괜찮)
즉, 객체는 대부분 일회성되며, 메모리에 오랫동안 남는 경우는 드물다.
이러한 특성을 이용해 JVM 개발자들은 보다 효율적인 메모리 관리를 위해,
객체의 생존 기간에 따라 물리적인 Heap 영역을 Young과 Old로 나눔
Young Generation (Young 영역)
새롭게 생성되는 객체가 할당되는 영역
대부분의 객체가 금방 Unreachable 되기 때문에 많은 객체가 할당되었다가 사라진다.
Young 영역에 대한 가비지 컬렉션을 Minor GC라고 부른다.
Old Generation (Old 영역)
Young영역에서 Reachable 상태를 유지하여 살아남은 객체가 복사되는 영역
Young 영역보다 크게 할당되며, 영역의 크기가 큰 만큼 가비지는 적게 발생한다.
Old 영역에 대한 가비지 컬렉션(Garbage Collection)을 Major GC 또는 Full GC라고 부른다.
위 그림에서, Old 영역이 Young 영역보다 크게 할당되는 이유는
Young 영역의 수명이 짧은 객체들은 큰 공간을 필요로 하지 않으며
큰 객체들은 Young 영역이 아니라 바로 Old 영역에 할당되기 때문이다.
또 다시 힙 영역은 더욱 효율적인 GC를 위해 Young 영역을 3가지 영역 (Eden, Survivor 0, Survivor 1)로 나눈다.
Eden
new를 통해 새로 생성된 객체가 위치
정기적인 쓰레기 수집 후 살아남은 객체들은 Survivor 영역으로 보냄
Survivor 1 / Survivor 2
최소 1번의 GC 이상 살아남은 객체가 존재하는 영역
Survivor 영역에는 특별한 규칙 : 둘 중 하나는 꼭 비어 있어야 함.
하나의 힙 영역을 세부적으로 쪼갬으로서 객체의 생존 기간을 면밀하게 제어하여
가비지 컬렉터(GC)를 보다 정확하게 불필요한 객체를 제거하는 프로세스를 실행하도록 한다.
[ Java 8 에서의 Permanent ]
클래스 로더에 의해 load되는 Class, Method 등에 대한 Meta 정보가 저장되는 영역이고 JVM에 의해 사용
Java 7 까지는 힙 영역에 존재했지만 Java 8 버전 이후에는 Native Method Stack에 편입
Minor GC 과정
Young Generation 영역은 짧게 살아남는 메모리들이 존재하는 공간이다.
모든 객체는 처음에는 Young Generation에 생성
Young Generation의 공간은 상대적으로 작기 때문에 메모리 상의 객체를 찾아 제거하는데 적은 시간이 걸린다. (작은 공간에서 데이터를 찾으니까)
이 때문에 Young Generation 영역에서 발생되는 GC를 Minor GC라 불린다.
1. 처음 생성된 객체는 Young Generation 영역의 일부인 Eden 영역에 위치
2. 객체가 계속 생성되어 Eden 영역이 꽉차게 되고 Minor GC가 실행
3. Mark 동작을 통해 reachable 객체를 탐색
4. Eden 영역에서 살아남은 객체는 1개의 Survivor 영역으로 이동
5. Eden 영역에서 사용되지 않는 객체(unreachable)의 메모리를 해제(sweep)
6. 살아남은 모든 객체들은 age값이 1씩 증가
[ age 값이란? ]
Survivor 영역에서 객체의 객체가 살아남은 횟수를 의미하는 값이며, Object Header에 기록
만일 age 값이 임계값에 다다르면 Promotion(Old 영역으로 이동) 여부를 결정
JVM 중 가장 일반적인 HotSpot JVM의 경우 이 age의 기본 임계값은 31, 객체 헤더에 age를 기록하는 부분이 6 bit로 되어 있기 때문
또한 Survivor 영역의 제한 조건으로 Survivor 영역 중 반드시 1개는 사용되어야 하고, 나머지는 비어 있어야 한다.
만약 두 Survivor 영역에 모두 데이터가 존재하거나, 모두 사용량이 0이라면 현재 시스템이 정상적인 상황이 아니라는 반증이 된다.
[Java 객체의 메모리 구조]
[Object Header (12 bytes)]
├── Mark Word (8 bytes)
│ ├── hash code
│ ├── GC age (survival count)
│ ├── lock state
│ └── thread ID
│
└── Class Pointer (4 bytes)
└── 클래스 메타데이터 주소
[Instance Data]
└── 실제 객체 데이터
class Person {
int age; // 4 bytes
String name; // 참조값 4 bytes
}
Person p = new Person();
// 실제 메모리:
// [Object Header 12bytes][age 4bytes][name 4bytes]
- 모든 객체는 헤더를 가짐
- GC age는 Mark Word 안에 저장
- 객체가 Survivor 영역으로 이동할 때마다 이 age값이 증가
7. 또다시 Eden 영역에 신규 객체들로 가득 차게 되면 다시한번 minor GC 발생하고 mark 한다 (반복)
8. marking 한 객체들을 비어있는 Survival 1으로 이동하고 sweep
10. 다시 살아남은 모든 객체들은 age가 1씩 증가
11. 이러한 과정을 반복
Major GC 과정
Old Generation은 길게 살아남는 메모리들이 존재하는 공간
Old Generation의 객체들은 거슬러 올라가면 처음에는 Young Generation에 의해 시작되었으나,
GC 과정 중에 제거되지 않은 경우 age 임계값이 차게되어 이동된 녀석들이다.
그리고 Major GC는 객체들이 계속 Promotion되어 Old 영역의 메모리가 부족해지면 발생하게 된다.
1. 객체의 age가 임계값(여기선 8로 가정)에 도달하게 되면,
2. 이 객체들은 Old Generation 으로 이동된다. 이를 promotion 이라 부른다.
3. 위의 과정이 반복되어 Old Generation 영역의 공간(메모리)가 부족하게 되면 Major GC가 발생되게 된다.
Major GC는 Old 영역은 데이터가 가득 차면 GC를 실행하는 단순한 방식이다.
Old 영역에 할당된 메모리가 허용치를 넘게 되면, Old 영역에 있는 모든 객체들을 검사하여
참조되지 않는 객체들을 한꺼번에 삭제하는 Major GC가 실행되게 된다.
하지만 Old Generation은 Young Generation에 비해 상대적으로 큰 공간을 가지고 있어,
이 공간에서 메모리 상의 객체 제거에 많은 시간이 걸리게 된다.
예를들어 Young 영역은 일반적으로 Old 영역보다 크키가 작기 때문에 GC가 보통 0.5초에서 1초 사이에 끝난다.
그렇기 때문에 Minor GC는 애플리케이션에 크게 영향을 주지 않는다.
하지만 Old 영역의 Major GC는 일반적으로 Minor GC보다 시간이 오래걸리며, 10배 이상의 시간을 사용한다.
바로 여기서 본문 초반에 소개했던 Stop-The-World 문제가 발생하게 된다.
Major GC가 일어나면 Thread가 멈추고 Mark and Sweep 작업을 해야 해서
CPU에 부하를 주기 때문에 멈추거나 버벅이는 현상이 일어나기 때문이다.
따라서 자바 개발자들은 끊임없이 가비지 컬렉션 알고리즘을 발전시켜왔다.
가비지 컬렉션 알고리즘 종류
JVM이 메모리를 자동으로 관리해주는 것은 개발자의 입장에서 상당한 메리트이다.
하지만 문제는 GC를 수행하기 위해 Stop The World가 발생되고 이 때문에 애플리케이션이 중지되는 문제점이 발생하게 되는 것
또한 자바가 발전됨에 따라 Heap의 사이즈가 커지면서 애플리케이션의 지연(Suspend) 현상이 두드러지게 되었고,
이를 최적화 위해 다양한 Garbage Collection(가비지 컬렉션) 알고리즘이 개발 되었다.
※ 다음의 GC 알고리즘은 모두 설정을 통해 Java에 적용가능
Serial GC
- 서버의 CPU 코어가 1개일 때 사용하기 위해 개발된 가장 단순한 GC
- GC를 처리하는 쓰레드가 1개 (싱글 쓰레드) 이어서 가장 stop-the-world 시간이 길다
- Minor GC 에는 Mark-Sweep을 사용하고, Major GC에는 Mark-Sweep-Compact를 사용한다.
- 보통 실무에서 사용하는 경우는 없다 (디바이스 성능이 안좋아서 CPU 코어가 1개인 경우에만 사용)
자바 프로그램을 실행할때 `-XX:+UseSerialGC` GC 옵션을 지정하여 사용
java -XX:+UseSerialGC -jar Application.java
Parallel GC
- Java 8의 디폴트 GC
- Serial GC와 기본적인 알고리즘은 같지만, Young 영역의 Minor GC를 멀티 쓰레드로 수행 (Old 영역은 여전히 싱글 쓰레드)
- Serial GC에 비해 stop-the-world 시간 감소
GC 스레드는 기본적으로 cpu 개수만큼 할당
옵션을 통해 GC를 수행할 쓰레드의 갯수 등을 설정
bashjava -XX:+UseParallelGC -jar Application.java
# -XX:ParallelGCThreads=N : 사용할 쓰레드의 갯수Copy
Parallel Old GC (Parallel Compacting Collector)
- Parallel GC를 개선한 버전
- Young 영역 뿐만 아니라, Old 영역에서도 멀티 쓰레드로 GC 수행
- 새로운 가비지 컬렉션 청소 방식인 Mark-Summary-Compact 방식을 이용 (Old 영역도 멀티 쓰레드로 처리)
Sweep의 경우 단일 스레드가 Old 영역을 찾아 살아있는 객체만 찾아내는 방식
Summary의 경우 여러 스레드가 Old 영역을 나눠 병렬적으로 찾음
java -XX:+UseParallelOldGC -jar Application.java
# -XX:ParallelGCThreads=N : 사용할 쓰레드의 갯수
CMS GC (Concurrent Mark Sweep)
- 어플리케이션의 쓰레드와 GC 쓰레드가 동시에 실행되어 stop-the-world 시간을 최대한 줄이기 위해 고안된 GC
- 단, GC 과정이 매우 복잡해짐.
- GC 대상을 파악하는 과정이 복잡한 여러단계로 수행되기 때문에 다른 GC 대비 CPU 사용량이 높다
- 메모리 파편화 문제
- CMS GC는 Java9 버젼부터 deprecated 되었고 결국 Java14에서는 사용이 중지
# deprecated in java9 and finally dropped in java14
java -XX:+UseConcMarkSweepGC -jar Application.javaCopy
G1 GC (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 빈도가 줄어드는 효과를 얻게 되는 원리
[ G1 GC의 효율성 ]
Java9+ 부터 기본 GC로 자리잡은 G1 GC에서는 이전의 GC들처럼 일일히 메모리를 탐색해 객체들을 제거하지 않는다.
대신 메모리가 많이 차있는 영역(region)을 인식하는 기능을 통해 메모리가 많이 차있는 영역을 우선적으로 GC 한다.
즉, G1 GC는 Heap Memory 전체를 탐색하는 것이 아닌 영역(region)을 나눠 탐색하고 영역(region)별로 GC가 일어난다.
또한 이전의 GC 들은 Young Generation에 있는 객체들이 GC가 돌때마다 살아남으면
Eden → Survivor0 → Survivor1으로 순차적으로 이동했지만, G1 GC에서는 순차적으로 이동하지는 않는다.
대신 G1 GC는 더욱 효율적이라고 생각하는 위치로 객체를 Reallocate(재할당) 시킨다.
예를 들어 Survivor1 영역에 있는 객체가 Eden 영역으로 할당하는 것이 더 효율적이라고 판단될 경우 Eden 영역으로 이동
java -XX:+UseG1GC -jar Application.java
Shenandoah GC
- Java 12에 release
- 레드 햇에서 개발한 GC
- 기존 CMS가 가진 단편화, G1이 가진 pause의 이슈를 해결
- 강력한 Concurrency와 가벼운 GC 로직으로 heap 사이즈에 영향을 받지 않고 일정한 pause 시간이 소요가 특징
Shenandoah GC 실행 명령어
java -XX:+UseShenandoahGC -jar Application.javaCopyZGC (Z Garbage Collector)
- Java 15에 release
- 대량의 메모리(8MB ~ 16TB)를 low-latency로 잘 처리하기 위해 디자인 된 GC
- G1의 Region 처럼, ZGC는 ZPage라는 영역을 사용하며, G1의 Region은 크기가 고정인데 비해, ZPage는 2mb 배수로 동적으로 운영됨. (큰 객체가 들어오면 2^ 로 영역을 구성해서 처리)
- ZGC가 내세우는 최대 장점 중 하나는 힙 크기가 증가하더도 'stop-the-world'의 시간이 절대 10ms를 넘지 않는다는 것
ZGC 실행 명령어
java -XX:+UnlockExperimentalVMOptions -XX:+UseZGC -jar Application.javaCopy☕ 가비지 컬렉션 동작 원리 & GC 종류 💯 총정리
Garbage Collection(GC) 이란? 가비지 컬렉션(Garbage Collection, 이하 GC)은 자바의 메모리 관리 방법 중의 하나로 JVM(자바 가상 머신)의 Heap 영역에서 동적으로 할당했던 메모리 중 필요 없게 된 메모리 객
inpa.tistory.com