JVM 이해

GC와 성능의 “직접 연결 고리”

자바에서 성능이란?

• TPS
• 응답시간(latency)
• 타임아웃
• 순간 멈춤

이 중 GC가 직접 깨는 건 딱 하나입니다.

👉 응답시간 (latency)

 

 

1️⃣ G1 / ZGC / CMS 차이

■ CMS (Concurrent Mark Sweep)

구세대, “멈춤 줄이려다 관리 지옥 간 GC”

• Old 영역을 **동시(concurrent)**로 마킹
• Stop-The-World 최소화 목적
• 단점
  • 메모리 단편화 심각
  • Full GC 발생 시 재앙
  • 튜닝 난이도 높음
• 현실
  • Java 8 레거시에서만 존재
  • 이미 사장됨 (Deprecated → Removed)

👉 “옛날에 썼다” 정도만 알면 됨

---

■ G1 (Garbage First)

현실적 표준, 공공·SI의 기본값

• 힙을 Region 단위로 쪼갬
• Garbage가 많은 Region부터 수거
• Pause 목표 기반 GC
  (-XX:MaxGCPauseMillis)
• 장점
  • 예측 가능한 Pause
  • 대용량 힙(수 GB~수십 GB)에 안정적
• 단점
  • Throughput은 Parallel GC보다 떨어짐
  • 설정 과신하면 오히려 느려짐

👉 “조절 가능한 현실형 GC”

---

■ ZGC

최신, “Pause가 거의 사라진 GC”

• Pause 수 ms 이하 (1~10ms)
• Load Barrier + Colored Pointer
• 힙 크기 수백 GB도 가능
• 장점
  • 초저지연
  • Full GC 개념 사실상 없음
• 단점
  • JVM/OS 요구사항 높음
  • CPU·메모리 오버헤드
  • 운영 경험 부족
• 현실
  • 금융·대규모 플랫폼
  • 공공·SI에서는 아직 과함

👉 “설명은 하되, 남용은 금물”

---

📌 GC 선택 감각

• Java 8 공공 SI → G1
• Java 17 이상, 초저지연 → ZGC
• CMS → 레거시 설명용

---

2️⃣ Eden / Survivor / Old 개념

■ Young Generation 구조

 

Eden → Survivor(S0/S1) → Old

■ Eden

• 객체 처음 생성
• 대부분 여기서 죽음
• Minor GC 대상

■ Survivor (S0 / S1)

• Eden에서 살아남은 객체 임시 보관
• GC마다 Ping-Pong 이동
• 여기서 일정 횟수 생존 시 Old 승격

■ Old Generation

• 장수 객체
• Full / Mixed GC 대상
• 여기서 GC 터지면 체감 성능 급락

---

핵심 실무 포인트

• 성능 문제 = Old에 객체가 쌓이는 구조
• Eden GC는 자주 발생해도 정상
• Old GC가 잦으면 설계 실패

---

3️⃣ JVM 옵션: -Xms / -Xmx / MaxGCPauseMillis

■ -Xms (초기 힙)

• JVM 시작 시 힙 크기
• 너무 작으면 → 초반 GC 폭증
• 실무: -Xms = -Xmx 권장

---

■ -Xmx (최대 힙)

• JVM이 쓸 수 있는 최대 메모리
• 무작정 키우면:
  • Full GC 한 번에 서버 멈춤
  • OS 메모리 압박

👉 “힙 크기는 성능이 아니라 리스크”

---

■ -XX:MaxGCPauseMillis

• G1의 목표값
• “이 시간 안에 끝내려고 노력하겠다”는 선언
• 보통 100~200ms

⚠️ 주의

• 낮게 잡으면 → GC 빈도 증가
• 높게 잡으면 → Pause 길어짐

👉 절대값 보장 아님

---

4️⃣ 이걸 다 안다는 의미 (중요)

이 3가지를 안다는 건:

• GC 로그를 읽을 수 있다
• GC 때문에 느린지 판단할 수 있다
• 옵션으로 완화는 가능

❌ 하지만:

• 성능을 “통제”하진 못함
• 구조가 나쁘면 GC는 무조건 터짐

---

5️⃣ 실무자 한 줄 요약

GC는 튜닝 대상이 아니라, 설계 결과다.
옵션은 마지막에 만지는 소화제다.