Oracle의 공식문서 HotSpot Virtual Machine Garbage Collection Tuning Guide을 참고했습니다.
📍 Serial Collector
📍 Parallel Collector
📍 Garbage-First (G1) Garbage Collector
📍 The Z Garbage Collector
📍 Selecting a Collector
📍 개요
지금까지의 논의는 Serial Collector(직렬 가비지 컬렉터) 에 대한 것이었다.
Java HotSpot VM은 서로 다른 성능 특성을 가진 세 가지 종류의 가비지 컬렉터를 제공한다.
🔎 Serial Collector (직렬 가비지 컬렉터)
Serial Collector 는 단일 스레드(single thread) 를 사용하여 모든 가비지 컬렉션 작업을 수행한다.
스레드 간의 통신 오버헤드가 없기 때문에 상대적으로 효율적이다.
📌 특징
- 단일 프로세서(single processor) 환경에서 가장 적합함.
- 다중 프로세서 환경에서도 데이터셋이 작을 경우(약 100MB 이하) 유용할 수 있음.
- 특정 하드웨어 및 운영 체제에서 기본적으로 선택되기도 함.
- 명시적으로 활성화하는 옵션 →
-XX:+UseSerialGC
🔎 Parallel Collector (병렬 가비지 컬렉터)
Parallel Collector 는 Throughput Collector(처리량 중심 가비지 컬렉터) 라고도 불린다.
Serial Collector 와 동일한 세대별(GC generational) 방식을 사용하지만,
여러 개의 스레드를 활용하여 GC 속도를 향상시키는 점에서 차이가 있다.
📌 특징
- 중간~대형 데이터셋을 가진 애플리케이션에 적합.
- 멀티프로세서(Multiprocessor) 및 멀티스레드(Multithreaded) 환경에서 성능을 극대화할 수 있음.
- 명시적으로 활성화하는 옵션 →
-XX:+UseParallelGC
🔎 Garbage-First (G1) Garbage Collector (G1 가비지 컬렉터)
G1 가비지 컬렉터 는 부분적으로 동시(concurrent) 실행되는 가비지 컬렉터이다.
즉, 애플리케이션이 실행되는 동안에도 일부 가비지 컬렉션 작업을 수행할 수 있다.
📌 특징
- 작은 시스템부터 대형 멀티코어 시스템까지 확장 가능.
- 응답 속도(Response Time) 보장 가능 → 일정한 GC 중단 시간 목표(Pause-Time Goal) 충족 가능.
- 높은 처리량(Throughput) 유지 가능.
- 대부분의 하드웨어 및 운영 체제에서 기본 선택됨.
- 명시적으로 활성화하는 옵션 →
-XX:+UseG1GC
🔎 The Z Garbage Collector (ZGC)
ZGC 는 최대 중단 시간을 1ms 이하로 유지할 수 있는 완전 동시(concurrent) 가비지 컬렉터이다.
이는 처리량(Throughput) 의 일부 손실을 감수하는 대신 낮은 지연시간(Low Latency) 을 보장한다.
📌 특징
- 초저지연(Low Latency) 애플리케이션에 적합.
- 힙 크기와 무관하게 일정한 중단 시간 유지 가능.
- 수백 MB~최대 16TB까지의 힙 크기 지원.
- Generational ZGC 도 지원하여 세대별 관리 방식과 동시 수행 결합 가능.
- 명시적으로 활성화하는 옵션
-XX:+UseZGC -XX:+ZGenerational→ 세대별(Generational) ZGC 사용-XX:+UseZGC→ 비세대별(Non-generational) ZGC 사용-XX:+UseZGC -XX:-ZGenerational→ 기존 방식의 ZGC 사용
🔎 가비지 컬렉터 선택 가이드
애플리케이션에 특별한 중단 시간(Pause Time) 요구 사항이 없다면,
우선 기본 설정으로 실행한 후 JVM이 선택하는 가비지 컬렉터를 사용하도록 한다.
성능이 충분하지 않다면 힙 크기(Heap Size) 를 조정하여 최적화를 시도한 후,
필요하면 아래 가이드를 참고하여 적절한 가비지 컬렉터를 선택할 수 있다.
| 애플리케이션 요구 사항 | 추천 가비지 컬렉터 | 옵션 |
|---|---|---|
| 데이터셋이 작음 (~100MB 이하) | Serial Collector | -XX:+UseSerialGC |
| 단일 프로세서에서 실행 & 중단 시간 신경 안 씀 | Serial Collector | -XX:+UseSerialGC |
| 최대 성능(Throughput)이 우선 & 1초 이상의 중단 시간 허용 가능 | Parallel Collector | -XX:+UseParallelGC |
| 응답 속도(Response Time) 중요 & 중단 시간을 줄이고 싶음 | G1 Collector | -XX:+UseG1GC |
| 응답 속도가 가장 중요 & 초저지연(ultra-low latency) 필요 | ZGC | -XX:+UseZGC -XX:+ZGenerational |
📌 각 가비지 컬렉터의 사용 예시
1️⃣ Serial Collector (단일 스레드, 작은 데이터셋)
✅ 사용 예시
- 임베디드 시스템 (IoT 기기, 라즈베리파이 등)
- 간단한 CLI 유틸리티 프로그램
- 개발/테스트용 작은 애플리케이션
💡 이유
- 단일 스레드에서 동작하므로 CPU가 하나인 환경에서 효율적
- 작은 힙 크기(100MB 이하)에서 오버헤드가 적음
- 멀티스레드 환경이 아니라도 충분한 성능 제공
2️⃣ Parallel Collector (멀티스레드, 높은 처리량)
✅ 사용 예시
- 배치 처리 시스템 (로그 분석, 데이터 마이닝)
- 대량의 트랜잭션을 처리하는 금융 애플리케이션
- 백그라운드 작업이 많은 서버 (ETL, 데이터 처리)
💡 이유
- 멀티코어 환경에서 GC를 병렬로 실행해 처리량(Throughput) 극대화
- 짧은 중단 시간보다는 전체 작업량을 빠르게 처리하는 것이 중요할 때 유리
3️⃣ Garbage-First (G1) GC (짧은 중단 시간, 균형 잡힌 성능)
✅ 사용 예시
- 웹 애플리케이션 (Spring Boot, Tomcat, Microservices)
- 게임 서버 (MMORPG, 대규모 멀티플레이어)
- 일반적인 엔터프라이즈 애플리케이션
💡 이유
- 짧고 예측 가능한 중단 시간 → 사용자 경험(UX) 향상
- 중간~대형 힙(수GB 이상)에서도 안정적인 성능 제공
- 대부분의 애플리케이션에서 기본 GC로 선택됨
4️⃣ Z Garbage Collector (초저지연, 대형 힙)
✅ 사용 예시
- 실시간 금융 거래 시스템 (주식, 암호화폐 거래소)
- AI/머신러닝 애플리케이션 (TensorFlow, PyTorch)
- 클라우드 서비스, SaaS (Slack, AWS Lambda)
- 대용량 데이터를 다루는 NoSQL 데이터베이스 (Cassandra, MongoDB)
💡 이유
- 중단 시간 1ms 이하 → 실시간 응답성이 중요한 환경에 적합
- 대용량 힙 (수백 GB~TB까지 지원)
- GC 오버헤드 최소화 → 지연 시간을 줄여야 하는 애플리케이션에 적합
💡 추가적인 튜닝 방법
- 추천된 컬렉터로도 원하는 성능이 나오지 않을 경우:
- 힙 크기(Heap Size) 및 세대 크기(Generation Size) 조정.
- 중단 시간이 너무 길다면 G1GC 또는 ZGC로 변경.
- 처리량(Throughput) 최적화가 필요하면 ParallelGC 사용.
