[REVIEW] JVM 밑바닥까지 파헤치기 - 3.2 가비지 컬렉터 종류, 로그, 메모리 할당과 회수 전략

클래식 가비지 컬렉터

클래식 가비지 컬렉터는 고성능 및 저지연 컬렉터와 구분하기 위해 사용되는 용어로, 핫스팟 가상 머신에서 제공하는 전통적인 가비지 컬렉션 방식들을 포함한다. 이 컬렉터들은 각각의 특성에 따라 메모리 관리를 수행하며, 주로 다음과 같은 종류가 있다:

1. 시리얼(Serial) 가비지 컬렉터: 단일 스레드를 사용하여 가비지 컬렉션을 수행한다. 간단하고 효율적이며, 작은 애플리케이션이나 리소스가 제한된 환경에서 적합하다.
2. 파뉴(Parallel) 가비지 컬렉터: 여러 스레드를 사용하여 가비지 컬렉션을 병렬로 수행한다. CPU를 효율적으로 활용하여 짧은 시간 안에 메모리를 회수할 수 있지만, 여전히 일시 정지가 발생할 수 있다.
3. 패러렐 스캐빈지(Parallel Scavenge) 가비지 컬렉터: 파뉴와 유사하지만, 짧은 일시 정지 시간과 높은 처리량을 목표로 한다. 객체의 생존 주기를 고려하여 신세대 객체의 회수를 최적화한다.
4. 패러렐 올드(Parallel Old) 가비지 컬렉터: 구세대(Old Generation)에서 가비지 컬렉션을 병렬로 수행하는 컬렉터로, 패러렐 스캐빈지 컬렉터와 함께 사용된다.
5. 시리얼 올드(Serial Old) 가비지 컬렉터: 단일 스레드를 사용하여 구세대의 가비지 컬렉션을 수행한다. 자원이 제한된 환경에서 효과적이며, 다른 시리얼 컬렉터와 함께 사용할 수 있다.
6. CMS(Concurrent Mark-Sweep) 가비지 컬렉터: 동시(mark-sweep) 방식으로 구세대 객체를 회수하는 컬렉터로, 응답성이 중요한 애플리케이션에 적합하다. 사용자가 지정한 시점에 가비지 컬렉션을 수행할 수 있어 일시 정지 시간을 줄이는 데 기여한다.

병렬과 동시
병렬과 동시는 모두 '동시성 프로그래밍'과 관련된 기술 용어이다. 

- 병렬(parallel) : GC 스레드들 사이의 관계를 설명하며, 'GC 스레드 다수가' 동시에 함께 작업을 수행한다. 보통 이때 사용자 스레드는 정지 상태다.
- 동시(concurrent) : GC 스레드와 사용자 스레드의 관계를 설명하며, 'GC 스레드와 사용자 스레드가' 동시에 일을 진행한다는 뜻이다. 사용자 스레드가 멈춰 있지 않아 애플리케이션이 서비스 요청에 응답할 수 있다. 하지만 GC 스레드가 시스템 자원 일부를 점유하므로 애플리케이션의 처리량은 평소보다 낮아질 수 있다.

 

 

1. 시리얼 컬렉터

• 가장 기초적이로 오래된 컬렉터
• 단일 스레드
• 가비지 컬렉션이 시작되면 '회수가 완료될 때까지 다른 모든 작업 스레드가 멈춰 있어야 한다.
• 가용 메모리가 적은 환경에서는 알고리즘 자체가 요구하는 메모리 사용량이 가장 적다. 
• 단일 코어 프로세서 또는 코어 수가 적은 환경이라면 시리얼 컬렉터는 스레드 상호 작용에 의한 오버헤드가 없다.
• 가비지 컬렉션에 집중하므로 자연스럽게 회수 효율을 최대로 끌어낸다.
• 시리얼 컬렉터를 사용하기 위해서는 -XX:+UserSerialGC 매개변수를 추가하면 된다.

 

2. 파뉴 컬렉터

• 여러 스레드를 활용하여 시리얼 컬렉터를 병렬화한 버전이다.
• 스레드 회수에 멀티스레드를 이용한다.
• GC 스레드와 사용자 스레드가 동시에 실행되는것을 최초로 실현해 냈다.
• 핫스팟 가상 머신 역사에서 사라진 최초의 가비지 컬렉터
• 단일 코어 프로세서에서는 시리얼 컬렉터보다 성능이 떨어진다.
• 스레드들의 상호 작용에 따른 오베허드 존재
• 코어수가 늘어나면 파뉴는 가비지 컬렉션을 하는 동안에 시스템 자원을 효율적으로 사용할 가능성이 커진다.

 

3. 패러렐 스캐빈지 컬렉터

• 신세대용이며, PS 컬렉터라고도 불린다.
• 마크-카피 알고리즘에 기초하며, 여러 스레드를 이용해 회수한다.
• 프로세서가 사용자 코드를 실행하는 데 사용하는 시간과 프로세서가 소비하는 총시간의 비율을 뜻하는 처리량을 제어하는 게 목표다.
• 처리량에 관심이 많아 처리량 컬렉터라고ㅗ 부르기도 한다.
•  -XX:MaxGCPauseMillis : 가비지 컬렉션 정지 시간의 최댓값을 지정. 컬렉터는 메무리 회수에 소용되는 시간이 이 설정값을 넘지 않는다.
•  -XX:GCTimeRatio: 처리량을 직접 지정. 애플리케이션의 총 실행 시간에 대한 가비지 컬렉션 시간의 배율
• -XX:+UserAdaptiveSizePolicy : 신세대의 크기, 에덴과 생존자의 공간 비율, 구세대로 옮겨갈 객체의 크기 등. 세부 설정 매개변수를 지정하지 않아도 된다. 가상 머신이 성능 모니터링 정보를 수집하여 최적의 정지 시간과 최대 처리량을 제공할 수 있도록 모든 매개 변수의 값을 동적으로 조율해 준다. GC 인간 공학이라고도 한다.
• 가상머신이 메모리 관리 최적화를 해주므로 수동으로 최적화하기 어려운 운영자에게는 적응형 조율 전략을 지원하는 PS 컬렉터가 괜찮은 선택지이다.
• 적응형 조율 전략은 파뉴 컬렉터와 차별화하는 중요한 특성이다.

 

4. 시리얼 올드 컬렉터

• 시리얼 컬렉터의 구세대용 버전
• 단일 스레드 컬렉터, 마크-컴팩트 알고리즘 사용
• 주로 클라이언트용 핫스팟 가상 머신에서 사용한다.

 

5. 패러렐 올드 컬렉터

• PS 컬렉터의 구세대용 버전
• 멀티스레드를 이용한 병렬 회수를 지원하며 마크-컴팩트 알고리즘으로 구현되었다.
• 구세대 컬렉터들의 메모리 용량은 크고 하드웨어는 좋지만, 단일 스레드로 동작 하여 서버용 프로세서의 병렬 처리 역량을 끌어낼 수 없었다.
• 처리량이 중요하거나 프로세서 자원이 부족한 상황이라면 처리량을 중시하는 PS 컬렉터와 패러렐 올드 조합이 적합하다.
• 사용하기 위해서는 XX:+UserParallelGC 매개변수를 지정한다.

 

6. CMS 컬렉터

• 표시와 쓸기 단계 모두를 사용자 스레드와 동시에 수행한다.
• CMS 컬렉터의 목적은 가비지 컬렉션에 따른 일시 정지 시간을 최소로 줄이는 것이다.
• 자바 애플리케이션의 주력 분야는 인터넷 서비스의 백엔드와 브라우저 기반의 브라우저-서버 시스템이기 때문에 서비스 응답 시간이 중요하므로 시스템의 일시 정지 시간이 짧아야 사용자에게 더 나은 경험을 줄 수 있다. 
• 마크-스윕 알고리즘을 기초로 구현되었으며, 기존 컬렉터들보다 훨씬 복잡하게 동작한다.
• 전체 과정은 최초 표시 - 동시 표시 - 재표시 - 동시 쓸기 로 구성된다.
• "최초 표시"와 "재표시" 단계는 '스톱 더 월드' 방식이다.
• 최초 표시 단계에서는 GC 루트와 직접 연결된 객체들만 표시하기 때문에 아주 빠르게 끝난다. 
• 동시 표시 단계에서는 GC 루트와 직접 연결된 객체들로부터 시작해 객체 그래프 전체를 탐색한다. 시간이 오래 걸리지만 사용자 스레드를 멈추지 않고 GC 스레드와 동시에 실행된다.
• 재표시 단계에서는 동시 표시 도중 사용자 스레드가 참조 관계를 변경한 객체들을 바로잡는다. 이 단계의 일시 정지 시간은 보통 최초 표시 단계보다 살짝 길며, 동시 표시 단계보다는 훨씬 짧다.
• 동시 쓸기 단계에서는 죽은 객체들을 쓸어 담으며, 이 단계 역시 사용자 스레드를 멈추지 않고 동시에 수행한다.
• 중요한 특성은 전체 과정 중 가장 긴 동시 표시와 동시 쓸기 단계에서 사용자 스레드를 멈추지 않는다.
• CMS 컬렉터의 주요 장점은 애플리케이션 스레드와 병렬로 가비지 컬렉션을 수행하여 정지 시간을 최소화하는 것이다.
• CMS 컬렉터의 첫번째 단점은 프로세서 자원에 민감하다는 점이다. 가비지 컬렉션을 수행하는 GC 스레드가 애플리케이션과 프로세서 성능을 공유하기 때문에, CPU 사용량이 높은 애플리케이션에서는 성능 저하가 발생할 수 있다. 특히, 애플리케이션이 본래 많은 프로세서 리소스를 필요로 하는 경우, GC가 상당한 CPU를 점유하면서 사용자 프로그램의 실행 속도가 눈에 띄게 느려질 수 있다.
• CMS의 또 다른 단점은 부유 쓰레기(Floating Garbage)를 회수하지 못한다는 점이다. CMS의 동시 마킹 및 동시 스위핑 단계에서 애플리케이션 스레드는 계속 실행되므로, 이 과정에서 새로운 객체가 생성될 수 있다. 하지만 일부 객체는 마킹이 끝난 후에 가비지가 되어도, 해당 GC 사이클에서는 회수되지 않는다. 이러한 객체들을 부유 쓰레기라고 하며, 결국 다음 GC 사이클까지 메모리를 차지하게 된다. 이로 인해 동시 모드 실패가 발생할 가능성이 있다. 즉, CMS가 메모리를 충분히 확보하지 못하면 결국 Stop-the-World 방식의 전체 GC가 강제로 실행되면서 애플리케이션 응답 시간이 크게 증가할 수 있다. 따라서, CMS를 사용할 경우 가비지 컬렉션 동안에도 사용자 스레드가 원활히 실행될 수 있도록 충분한 메모리 공간을 확보하는 것이 중요하다.
• CMS의 또 다른 단점은 메모리 파편화 문제이다. CMS는 마크-스윕(Mark-Sweep) 방식으로 가비지를 정리하는데, 메모리를 압축하지 않기 때문에 파편화가 발생할 수 있다. 파편화가 심해지면 큰 객체를 할당할 때 연속된 메모리 공간을 찾지 못해 할당이 실패할 수 있다. 이 경우 결국 전체 GC(Full GC)를 실행하여 메모리를 정리해야 한다. 이 문제를 해결하기 위해 CMS는 -XX:+UseCMSCompactAtFullCollection 옵션을 제공한다. 이 옵션을 활성화하면 CMS가 Full GC를 수행할 때 메모리 조각 모음(Compaction)도 함께 실행한다. 하지만 이 과정에서 살아있는 객체를 이동해야 하므로, 사용자 스레드와 동시에 실행할 수 없고 정지 시간이 길어질 수 있다. 이를 보완하기 위해 JVM은 -XX:CMSFullGCsBeforeCompaction 옵션을 제공한다. 이 옵션은 지정된 횟수만큼 Full GC를 수행한 후에만 조각 모음을 실행하도록 설정할 수 있다. 즉, 모든 Full GC에서 조각 모음을 수행하는 것이 아니라, 일정 횟수 후에만 실행함으로써 정지 시간을 조절할 수 있도록 한 것이다.

자바 애플리케이션은 웹 서비스의 백엔드(서버 측 로직) 와 브라우저-서버 기반 시스템 개발에 많이 사용됩니다. 이러한 애플리케이션에서 가장 중요한 요소 중 하나가 서비스 응답 시간입니다. 서비스 응답 시간이란 사용자가 요청을 보낸 후 서버가 응답을 주는 데 걸리는 시간을 의미합니다. 응답 시간이 길어지면 사용자 경험(UX)이 나빠지고, 페이지 로딩 속도가 느려지거나 서비스가 끊기는 것처럼 보일 수 있습니다.
시스템의 "일시 정지 시간"이 중요한 이유는 자바는 가비지 컬렉터를 사용하여 메모리를 자동으로 관리합니다. 하지만 GC가 실행될 때 애플리케이션의 일부 또는 전체가 일시적으로 멈추는 "Stop-the-world" 현상이 발생할 수 있습니다. 이 일시 정지 시간이 길어지면, 서버가 클라이언트 요청을 즉시 처리하지 못하고 대기해야 합니다. 결과적으로 사용자는 서비스가 느려졌다고 느끼거나, 심한 경우 서비스가 멈춘 것처럼 보일 수 있습니다.

일시 정지 시간을 줄이는 방법
- GC 튜닝
   - 최신GC 알고리즘(예: G1GC, ZGC, Shenandoah GC) 활용
   - JVM 옵션 조정 (-XX:MaxGCPauseMillis 설정 등)

- 메모리 관리 최적화
   - 불필요한 객체 생성을 줄이고, 메모리 누수 방지
   - 객체 풀(Object Pool) 활용

- 비동기 및 병렬 처리 최적화
   - 요청을 비동기(Async) 방식으로 처리
   - 적절한 스레드 풀(Thread Pool) 설정

즉, "시스템의 일시 정지 시간이 짧아야 한다"는 말은 GC로 인해 애플리케이션이 멈추는 시간을 최소화하여, 서버가 항상 빠르게 응답할 수 있도록 해야 한다는 의미입니다.

 

 

7. G1 컬렉처(가비지 우선 컬렉터)

• Garbage First(가비지 우선)을 짧게 줄인 표현이다.
• 주로 서버용 애플리케이션에 집중한 컬렉터다.
• 힙 메모리의 어느곳이든 회수 대상에 포함할 수 있다. 이를 회수 집합이라 하며 짧게 CSet라고 한다. '어느 영역에 쓰레기가 가장 많으냐'와 '회수했을 때 이득이 어디가 가장 크냐'가 회수 영역을 고르는 기준이 된다. 이것이 G1의 혼합 GC 모드다.
• G1은 자바 힙을 동일 크기의 여러 독립 리전(블록)으로 나눠, 리전 각각에 역할별 전략을 구분하여 적용할 수 있어서 회수 효율을 극대화한다.
• 큰 객체를 저장하기 위해서는 거대리전(humongous region)이라는 특별한 유형을 활용한다. G1은 리전 용량의 절반보다 큰 객체를 큰 객체로 취급한다. 리전 하나의 크기는 -XX:G1HeapRegionSize 매개변수로 설정한다.

 G1 GC의 회수 효율 극대화 원리

1. 가비지가 많은 리전부터 우선 회수(Garbage First)
   • 기존의 GC는 전체 Young 또는 전체 Old 영역을 대상으로 GC를 수행하지만,
   • G1은 회수할 가치가 높은 리전부터 선택적으로 GC를 수행하여 최소한의 비용으로 최대한의 메모리를 회수한다.
2. 리전별 독립적인 GC 적용
   • 각 리전의 역할과 상태에 따라 최적의 GC 전략을 적용하여 불필요한 정지 시간을 줄인다.
   • 예를 들어, Young GC는 Young 리전에서만 수행되고, Mixed GC는 Young + Old 리전을 대상으로 수행된다.
3. 연속적인 메모리 확보(Compact) 기능 포함
   • CMS와 달리 메모리 파편화를 해결하기 위해 객체를 이동하여 연속적인 공간을 확보하는 Compact 기능이 포함되어 있다.
   • 따라서 큰 객체를 할당할 때 메모리 부족 문제가 발생하는 것을 방지할 수 있다.

G1 GC는 힙을 여러 개의 리전으로 나누고, 각 리전에 역할을 동적으로 할당하여 불필요한 GC 작업을 줄이고, 가장 효과적으로 회수할 수 있는 영역을 우선적으로 정리하여 GC 성능을 극대화하는 방식이다.

 

 

8. 오늘날의 가비지 컬렉터들

• 신세대용과 구세대용 구분이 사라졌다.

저지연 가비지 컬렉터

• 핫스팟의 가비지 컬렉터는 시리얼 -> CMS -> G1으로 진화했다.
• 가비지 컬렉터를 측정하는 가장 중요한 지표는 처리량, 지연시간, 메모리 사용량이다. 
• 하드웨어 성능이 향상되면서 메모리를 조금 더 사용하는 것은 큰 문제가 되지 않는다. 또한 성능이 좋은 가비지 컬렉터는 애플리케이션에 미치는 영향을 줄여 전체 처리량을 증가시킨다. 하지만 메모리를 늘리면 지연 시간이 길어지고 성능에 미묘한 영향을 줄 수 있다. 이러한 이유로 가비지 컬렉터에서 가장 중요한 성능 지표는 지연 시간이다.
• 셰년도어와 ZGG 컬렉터는 최초 표시와 최종 표시에서만 일시 정지가 짧게 일어나며, 일시 정지 시간은 거의 고정적이다. 즉, 힙 크기와 힙 안의 객체 수가 늘어난다고 해서 더 길어 지지 않는다. 그래서 이 두 컬렉터를 '저지연 가비지 컬렉터'라고 한다.

 

1. 셰년도어

• 오라클 가상 머신 개발팀이 주도하지 않은 첫번째 핫스팟 가비지 컬렉터라서 오라클 JDK에는 없고 다른 회사 OpenJDK에만 존재하는 컬렉터다.
• 힙을 리전들로 쪼개 처리하며, 큰 객체 전용의 거대 리전을 지원하고, 기본적으로 회수가치가 큰 리전을 먼저 회수한다. 
• 셰년도어의 목표는 힙 크기와 상관없이 가비지 컬렉션으로 인한 일시정지를 10밀리 초 이내로 묶어두는 것이었다.
• G1 컬렉터는 셰년도어의 코드를 반영하여 동시 실패의 탈출구인 전체 GC를 멀티스레드로 처리할 수 있게 되었다.

 

셰년도어의 개선사항

• 동시 모으기 지원
• 신세대 리전과 구세대 리전을 구별하지 않는다. 셰년도어에서 세대 구분은 복잡도와 일정을 고려해 개발 우선순위에서 낮췄다.
• 메모리와 컴퓨팅 자원을 많이 사용하는 기업 집합 대신 '연결 행렬'로 리전 간 참조 관계를 기록한다. 그 덕분에 관리 비용도 줄고 거짓 공유 문제가 발생할 가능성도 줄었다.

 

동작방식

1. 최초 표시
   1. 가장 먼저 GC 루트에서 직접 참조하는 객체들에 표시한다.
   2. 이 과정은 "Stop-The-World" 상태에서 실행되며, 빠르게 완료된다.
2. 동시 표시
   1. 객체 그래프를 타고 힙을 탐색하며 도달 가능한 모든 객체를 표시한다.
   2. 사용자 스레드와 동시에 수행된다.
   3. 수행 시가은 살아있는 객체 수와 객체 그래프의 복잡도에 따라 다르다.
   4. 사용자 스레드가 새로운 객체를 생성할 수 있으므로 힙 사용량이 늘어날 수 있다.
3. 최종 표시
   1. 보류 중인 모든 표시를 완료하고 GC 루트 집합을 다시 스캔한다.
   2. 회수가치가 가장 큰 리전들을 추려 회수 집합을 생성한다.
   3. 이 단계도 짧지만 일시 정지된다.
4. 동시 청소
   1. 살아 있는 객체가 하나도 없는 리전들을 청소한다.
5. 동시 이주
   1. 다른 핫스팟의 컬렉터들과 구분되는 핵심 차이
   2. 회수 집합 안에 살아 있는 객체들을 다른 빈 리전으로 복사한 후, 해당 객체를 가리키던 참조 모두가 여전히 이동 전 객체를 가리키고 있으므로 읽기 장벽과 포워딩 포인터를 이용한다. 
   3. 실행 시간은 회수 집합의 크기에 따라 다르다.
6. 최초 참조 갱신
   1. 참조 갱신 : 객체 이동에 따른 참조를 수정한다. 동시 이주 단계에서 객체를 복사한 다음, 힙에서 옛 객체를 가리키는 모든 참조를 복사 후의 새로운 주소로 수정한다.
   2. 애플리케이션이 계속 실행되는 동안 힙 내의 참조를 최신 상태로 업데이트한다
7. 동시 참조 갱신
   1. 참조 갱신을 시작하며 사용자 스레드와 동시에 수행한다.
   2. 수행 시간은 메모리에 존재하는 참조의 수에 따라 다르다.
   3. 물리 메모리 주소의 순서대로 참조 타입을 선형 검색하여 이전 값을 새로운 값으로 수정한다.
8. 최종 참조 갱신
   1. 힙의 참조를 다 갱신한 후, GC 루트 집합의 참조도 갱신한다.
   2. 셰년도어의 마지막 일시 정지 단계다.
   3. 정지 시간은 GC 루트의 개수에 따라 다르다.
9. 동시 청소
   1. 이주와 참조 갱신이 끝나면 회수 집합의 모든 리전에는 살아 있는 객체가 더 이상 남지 않는다.
   2. 그래서 동시 청소를 다시 수행하여 새로운 객체를 할당할 공간을 확보한다.

셰년도어의 가장 중요한 단계는 동시 표시, 동시 이주, 동시 참조 갱신이다. 

 

포워딩 포인터

• 셰년도어가 이주를 동시에 수행할 수 있도록 하는 핵심 개념이다.
• 객체 이동과 사용자 프로그램을 동시에 수행하는 방법
• 객체 이동 시 원래 위치에서 새로운 위치를 가리키는 역할을 하는 포인터이다. 주로 압축(Compaction) 또는 복사(Copying) 가비지 컬렉션 과정에서 사용된다.

 

포워딩 포인터가 필요한 이유

가비지 컬렉션 중 일부 알고리즘(예: Shenandoah GC, G1 GC, Copying GC)에서는 메모리 단편화(Fragmentation) 문제를 해결하기 위해 객체를 이동한다.
이 과정에서 기존 객체의 참조를 그대로 유지하려면 객체가 이동된 후에도 기존 참조들이 새 위치를 찾을 수 있도록 해야 한다.

이를 해결하기 위해 포워딩 포인터를 사용한다.

 

포워딩 포인터의 동작 방식

1. 객체 이동 전
   1. 객체가 힙 메모리의 한 위치(예: 주소 A)에 존재하고, 여러 참조가 해당 객체를 가리킨다.
2. 객체 이동 과정
   1. GC가 객체를 새로운 위치(예: 주소 B)로 이동한다.
   2. 원래 객체가 있던 자리(주소 A)에 포워딩 포인터를 저장하여 주소 B를 가리키도록 설정한다.
3. 참조 업데이트 과정
   1. 이후, 다른 객체나 스레드가 주소 A에 있는 객체를 참조하려고 하면, 포워딩 포인터를 따라 새 주소 B로 이동한다.
   2. GC는 모든 참조를 새로운 위치(B)로 업데이트한 후, 포워딩 포인터를 제거한다.

 

포워딩 포인터의 장점

• 객체 참조 유지 → 기존 참조가 깨지지 않고 새 위치를 찾을 수 있다.
• 메모리 단편화 해결 → 객체를 압축하면서도 참조 무결성을 유지할 수 있다.
• 애플리케이션의 중단 최소화 → 일부 GC 알고리즘은 객체를 이동하면서도 애플리케이션을 실행 가능하게 한다.

단점 및 주의

• 추가적인 메모리 사용 → 포워딩 포인터를 저장하는 공간이 필요하다.
• 참조 업데이트 비용 → 모든 참조를 새로운 위치로 변경해야 하므로 성능에 영향을 줄 수 있다.

 

2. ZGC

• 오라클이 개발한 저지연 가비지 컬렉터
• ZGC는 초저지연(Low-Latency) 가비지 컬렉터로, 최대 1~2ms 이하의 GC 일시 정지 시간(Pause Time)을 목표로 설계된 스케일러블(Scalable) GC이다.
• 셰년도어와 마찬가지로 둘 다 처리량에 미치는 영향을 최소로 억제하면서 힙 크기에 상관없이 가비지 컬렉션으로 인한 일시 정지 시간을 10밀리 초 안쪽으로 줄이고자 했다.
• 세대 구분 없이 리전 기반 메모리 레이아웃을 사용한다. 낮은 지연 시간을 최우선으로 목표로 하며, 동시 마크-컴팩트 알고리즘을 구현하기 위해 읽기 장벽, 컬러포인터, 메모리 다중 매핑 기술을 이용하는 가비지 컬렉터이다.

리전 기반 메모리 레이아웃

• ZGC의 리전은 동적으로 생성/파괴되며, 크기도 동적으로 달라진다.

병렬 모으기

• GC는 병렬 모으기(Parallel Compaction) 알고리즘을 사용하여 메모리 단편화(Fragmentation) 문제를 해결한다.
  즉, 객체를 이동(Compaction)시키면서 힙을 정리하는 과정을 여러 개의 스레드에서 병렬로 실행하여 GC 일시 정지 시간을 최소화하는 방식이다.

1. 일반적인 GC의 단편화 문제

일반적인 가비지 컬렉터는 객체를 제거하면서 힙 메모리에 빈 공간(단편화)이 발생한다.

• 단편화가 심해지면 큰 객체를 할당할 연속된 공간을 찾지 못해 할당 실패 발생한다.
• 해결하려면 객체를 이동하여 연속된 공간을 확보(Compaction) 해야 한다.
• 하지만 대부분의 GC는 Compaction 단계에서 스톱 더 월드(Stop-The-World, STW) 시간이 길어지는 문제가 있다.

ZGC는 병렬 모으기(Parallel Compaction)를 통해 이 문제를 해결한다.

 

2. ZGC의 병렬 모으기 방식

ZGC는 기존의 GC와 다르게 대부분의 객체 이동 작업을 애플리케이션과 동시에 진행한다.
이 과정에서 Forwarding Pointer(포워딩 포인터)와 Colored Pointer(컬러드 포인터)를 활용하여 객체 참조를 자동으로 업데이트한다.

 

병렬 모으기 3단계

ZGC의 Compaction 과정은 3단계로 이루어진다.

 

1. Prepare(준비 단계)

• 살아 있는 객체를 식별하고, 어떤 객체를 이동할지 결정
• 객체 이동이 필요한 리전을 선택

2. Relocation(객체 이동 단계)

• 객체를 새로운 위치로 병렬로 복사
• 이전 객체의 주소에 포워딩 포인터(Forwarding Pointer)를 저장하여 참조 자동 업데이트

3. Remapping(참조 업데이트 단계)

• 애플리케이션 실행 중 모든 참조를 새 주소로 자동 변경
• Colored Pointer를 사용하여 객체 참조를 실시간으로 리맵핑

이 과정에서 GC 일시 정지(Pause Time)는 1~2ms 이내로 유지된다.

 

3. 병렬 모으기의 핵심 기술

 1) 포워딩 포인터 (Forwarding Pointer)

• 객체가 이동되면 이전 위치에 새 위치 정보를 저장
• 참조된 객체를 자동으로 새로운 위치로 리디렉션 가능
• 덕분에 애플리케이션이 실행되는 동안에도 안전하게 객체 이동 가능

 2) 컬러드 포인터 (Colored Pointer)

• 64비트 포인터의 일부 비트를 활용해 객체의 상태를 저장
• 객체가 이동되었을 때, 참조를 자동으로 업데이트하여 추가적인 스톱 더 월드 과정 없이 GC 수행 가능

 

4. 병렬 모으기의 장점

• STW(Stop-The-World) 최소화 → GC 정지 시간이 1~2ms 이하로 유지됨
• 큰 힙(16TB)에서도 효율적인 메모리 정리 가능
• 멀티코어 CPU 활용 극대화 → 여러 스레드에서 객체 이동을 병렬로 수행
• 실시간 애플리케이션에 적합 → 응답 속도가 중요한 환경(실시간 시스템, 대규모 서버 환경)에서 강력한 성능을 발휘한다.

 

5. 병렬 모으기의 단점

• CPU 오버헤드 증가
  • GC가 애플리케이션과 병렬로 실행되므로 일부 CPU 리소스를 사용한다.
• Throughput(처리량) 감소 가능성
  • CPU를 활용한 GC 작업이 많아짐에 따라 처리량이 약간 줄어들 수 있다.

 

---

 

적합한 가비지 컬렉터 선택하기

• 자금은 여유롭지만 최적화 경험이 부족하다면 유료 기술 지원을 받을 수 있는 전용 하드웨어와 소프트웨어 솔루션이 좋은 선택이다. 이 경우 C4 컬렉터를 사용할 수 있다.
• 상용 제품을 쓸 여유는 없지만 소프트웨어와 하드웨어 모델을 제어할 능력이 된다면 최선 버전을 사용하자. 특히 지연 시간이 중요하다면 ZGC를 시도해 보자.
• 레거시 시스템을 물려받아서 하드웨어와 소프트웨어 시스템에서 운영해야 한다면 메모리 용량에 따라 선택하자. 힙 메모리가 4GB에서 6GB 이하면 CMS 가 괜찮을 것이고, 그보다 많다면 G1을 시도하자.
• 최대 100MB 정도의 작은 데이터를 다루는 애플리케이션이라면 시리얼 컬렉터.
• 애플리케이션이 단일 프로세서만 사용하고 일시 정지 시간 관련 제약이 없다면 시리얼 컬렉터.
• 애플리케이션의 최대 성능이 가장 중요하고, 지연 시간 관련 제약이 없거나 1초 이상의 지연 시간도 허용된다면 가상 머신의 기본 컬렉터나 패러렐 컬렉터.
• 처리량보다 응답 시간이 중요하고 가비지 컬렉션에 따른 일시 정지가 짧아야 한다면 G1
• 응답 시간이 매우 중요하면 (세대 구분) ZGC

 

가상 머신과 가비지 컬렉터 로그

• 자바 가상 머신의 메모리 문제를 다루려면 기본적으로 가상 머신과 가비지 컬렉터가 기록한 로그를 읽고 분석할 줄 알아야 한다.
• Java 9부터 -Xlog 옵션을 사용하면 JVM과 GC 로그를 설정할 수 있다. -Xlog 매개 변수로 모든 핫스팟 기능의 로그를 설정할 수 있게 되었고, 이 매개 변수 자체의 기능 역시 늘었다.

 

기본적인 -Xlog 사용법

- Xlog:<출력 대상>:<출력 수준>:<출력 태그>:<파일 경로>:<롤링 옵션>

• <출력 대상> → stdout, stderr, file=<파일 경로> 등
• <출력 수준> → trace, debug, info, warning, error
• <출력 태그> → gc, heap, safepoint, classload, jit 등
• <파일 경로> → 로그를 저장할 파일 경로 지정
• <롤링 옵션> → 파일 크기 및 개수 제한 (filecount=10, filesize=10MB 등)

 

GC 로그를 기록하는 -Xlog 예제

java -Xlog:gc=info:file=gc.log:time,uptime,level,tags

 

• gc=info → GC 관련 로그를 INFO 레벨로 출력
• file=gc.log → gc.log 파일에 기록
• time, uptime, level, tags → 로그에 시간, 실행 시간, 레벨, 태그 포함

 

다양한 GC 로그 설정 예제

• GC 이벤트만 로깅

java -Xlog:gc GCTest

기본 정보를 보려면 -Xlog:gc를 사용한다.

java -Xlog:gc=debug GCTest

debug 수준의 GC 이벤트를 표준 출력으로 기록

java -Xlog:gc* GCTest

gc 태그의 모든 하위 프로세스를 포함한 상세 정보

• 가비지 컬렉션 전후로 가용한 힙과 메서드 영역의 용량 변화를 확인

java -Xlog:gc+heap=debug GCTest

• 가비지 컬렉션 중 사용자 스레드의 동시 실행 시간과 일시 정지 시간을 확인

java -Xlog:safepoint GCTest

• GC 및 메모리 관련 로그를 파일로 저장

java -Xlog:gc*,heap=info:file=gc.log:time,level,tags

GC와 Heap 관련 INFO 로그를 gc.log 파일에 기록

 

• 회수 후 남은 객체들의 나이 분포 확인

java -Xlog:gc+age=trace GCTest

 

• JVM 내부 동작도 포함하여 상세 로그 기록

java -Xlog:gc*,safepoint,heap,metaspace=debug:file=jvm.log

GC, Safepoint, Heap, Metaspace 관련 DEBUG 로그를 jvm.log 파일에 기록

 

• 로그 파일 크기 제한 (10MB, 최대 5개 파일 유지)

java -Xlog:gc=info:file=gc.log:time,uptime,level,tags:filecount=5,filesize=10MB

gc.log 파일 크기를 최대 10MB로 설정, 최대 5개까지 유지

 

 

---

 

 

실전 : 메모리 할당과 회수 전략

자바 시스템의 자동 메모리 관리의 핵심 목표는 객체의 메모리를 자동으로 할당하고, 사용이 끝난 메모리를 자동으로 회수하는 것이다. 객체의 메모리 할당은 힙에서 이루어지며, 전통적인 세대별 설계에서는 새로 생성된 객체가 주로 신세대(Young Generation)에 할당된다.

하지만 객체의 할당 방식은 고정되지 않는다. 자바 가상 머신(JVM) 명세에서는 객체 생성과 저장 방식을 명확히 정의하지 않으며, 실제 동작 방식은 사용하는 가비지 컬렉터(GC)와 JVM 메모리 설정에 따라 달라질 수 있다.

 

1. 객체는 먼저 에덴에 할당된다.

객체는 먼저 에덴(Eden) 영역에 할당되며, 에덴의 공간이 부족해지면 마이너 GC(Minor GC)가 실행된다.

또한, 핫스팟 가상 머신(HotSpot JVM)의 -Xlog:gc* 옵션을 사용하면 가비지 컬렉션(GC) 시 메모리 회수 로그를 출력하며, 프로세스 종료 시 각 메모리 영역의 할당 상태도 확인할 수 있다. 실전에서는 GC 로그를 파일로 저장하여 전문 분석 도구를 활용해 분석하기도 한다.

 

2. 큰 객체는 곧바로 구세대에 할당된다.

큰 객체는 곧바로 구세대(Old Generation)에 할당된다. 여기서 큰 객체는 연속된 메모리 공간을 필요로 하는 자바 객체로, 매우 긴 문자열이나 원소가 많은 배열이 대표적인 예이다.

가상 머신에서 큰 객체의 등장은 바람직하지 않으며, 사라질 큰 객체들이 대량으로 생성되는 상황은 더욱 문제가 된다. 이러한 상황은 여유 공간이 많음에도 가비지 컬렉션(GC)을 자주 발생시키는 원인이 되기 때문이다.

큰 객체를 위한 연속된 공간을 확보하기 위해 다른 객체들을 이동해야 하므로 심각한 메모리 복사 오버헤드를 초래한다. 이 문제를 해결하기 위해 -XX:PretenureSizeThreshold 매개변수를 설정하면, 설정값보다 큰 객체를 곧바로 구세대에 할당하게 되어, 에덴과 두 생존자 공간 사이의 대규모 복사를 줄이는 데 기여한다.

-XX:PretenureSizeThreshold 매개 변수는 시리얼과 파뉴 신세대 컬렉터에만 적용된다. PS 컬렉터와 다른 컬렉터들은 이 매개변수를 지원하지 않는다. 

 

3. 나이가 차면 구세대로 옮겨진다.

핫스팟 가상 머신의 가비지 컬렉터는 힙 메모리 관리를 위해 세대 단위 컬렉션을 활용한다. 메모리를 청소할 때는 어떤 새로 생성된 객체를 신세대(Young Generation)에 남기고, 어떤 생존 객체를 구세대(Old Generation)로 옮길지를 결정해야 한다. 이를 위해 각 객체의 객체 헤더에 세대 나이 카운터가 포함되어 있다.

객체는 주로 에덴(Eden)에서 태어나며, 초기 나이는 0이다. 첫 번째 마이너 GC(Minor GC)에서 살아남은 객체는 생존자 공간(Survivor Space)으로 이동하고 나이가 1로 증가한다. 이후 생존자 공간에서 마이너 GC를 겪을 때마다 나이가 1씩 증가하며, 특정 나이에 도달하면 구세대로 승격된다.

구세대로 승격되는 나이는 -XX:MaxTenuringThreshold 매개변수로 설정할 수 있으며, 기본값은 가비지 컬렉터의 종류와 JDK 버전에 따라 달라진다.

-XX:TargetSurvivorRatio 매개변수를 지정하면 나이 상관없이 생존자 공간이 지정한 비율 이상 차면 살아남은 객체들을 구세대로 승격시킨다. 

 

공간이 비좁으면 강제로 승격시킨다.

다양한 프로그램의 메모리 사용 패턴에 더 정밀하게 대응하기 위해 핫스팟 가상 머신은 나이가 -XX::MaxTenuringThreshold보다 적어도 구세대로 승격시키기도 한다. '생존자 공간 점유율'이 조건이며, 기본값은 50%라서 생존 객체 전체의 크기 총합이 생존자 공간의 절반을 넘어서면 모든 객체를 구세대로 옮긴다.

 

 

 

 

 

 

 

참고

https://product.kyobobook.co.kr/detail/S000213057051

JVM 밑바닥까지 파헤치기 | 저우즈밍 - 교보문고