[Java] Garbage Collector, 왜 Serical GC가 돌아가고 있지???

개요

최근 새로운 서비스를 배포하면서 예상치 못한 것을 발견하게 되었습니다. 배포 후 이것저것 살펴보던 중, Garbage Collector (이하 GC)가 SerialGC로 사용되고 있는 것을 알게 되었습니다. 해당 서비스는 Java 17을 사용중이었고 요즘은 G1GC가 기본 아니었나? 라고 생각했기 때문이죠.

알고보니 JVM에 할당된 리소스 작을 경우 Serial GC를 기본으로 채택한다는 사실을 알게 되었습니다. 왜 그런지 아무래도 궁금하죠? 저두요~

 

 

 

일단 Serial GC 란??

Serial GC는 가장 단순한 형태의 가비지 컬렉터로, GC 작업을 단일 스레드로 처리합니다. Stop-the-world 방식으로 모든 애플리케이션 스레드를 멈추고 GC를 수행하며, 구현이 간단하고 오버헤드가 적습니다.

 

 

 

JVM은 언제 Serial GC를 선택할까??

JVM은 실행 환경에 따라 적절한 GC를 자동으로 선택합니다.

Java 17 기준으로 일반적으로 G1 GC를 사용하죠. 하지만 1 CPU이거나 가용 가능한 메모리가 1792MB 이하일때 HotSpot JVM ergonomics(JVM이 실행 환경과 애플리케이션 특성을 분석하여 성능을 자동으로 최적화하는 메커니즘)에 의해 Serial GC를 쓰도록 설정된다고 합니다. 

 

즉, JVM 힙 메모리가 작거나, 단일 CPU 환경에서 실행될 경우, JVM은 자동으로 SerialGC를 사용하게 됩니다. 이는 리소스 오버헤드를 최소화하고 빠른 GC 처리를 위해 설계된 전략입니다.

 

 

 

 

 

왜 JVM은 Serial GC를 선택할까??

1. 멀티스레드 GC의 이점이 사라짐

Parallel GC나 G1 GC는 GC 작업을 병렬 스레드로 처리해 GC 시간을 줄이지만, 단일 CPU 환경에서는 어차피 동시에 실행할 수 없으므로 오히려 오버헤드만 증가할 수 있습니다.

2. 오버헤드 최소화

멀티스레드 GC는 동기화, 스레드 생성 및 스케줄링 등의 부가적인 비용이 필요합니다. 단일 스레드로 작동하는 Serial GC는 이러한 오버헤드가 없기 때문에 단순하고 빠르게 GC 작업을 수행할 수 있습니다.

3. 단순한 구조가 안정성 향상

개발, 테스트, 경량 컨테이너 환경 등 리소스가 제한된 환경에서는 단순한 GC 동작이 더 예측 가능하고 안정적입니다.

 

 

 

결론 

단일 CPU 환경이나 작은 메모리 환경에서는 JVM이 자동으로 Serial GC를 선택할 수 있습니다. 

물론 배포하는 서비스를 이렇게 작은 리소스로 운영할 생각은 없었어서 설정을 바꾸긴 했습니다만, 새로운 서비스를 배포하거나 컨테이너나 리소스가 한정된 환경에서 애플리케이션을 실행할 때는 어떤 설정으로 서버를 띄웠는지 꼭 확인해보는 습관을 들이는 것과 상황에 맞는 GC를 선택하는 것이 중요하다는 것을 이번 경험을 통해 다시 한번 느꼈습니다.

 

 

 

 

참고

- https://inside.java/2022/08/08/sip063/

The Serial Garbage Collector - Sip of Java – Inside.java

- https://docs.oracle.com/en/java/javase/18/gctuning/available-collectors.html#GUID-9E4A6B11-BB94-424F-90EF-401287A1C333

HotSpot Virtual Machine Garbage Collection Tuning Guide