가비지 컬렉터와 TLAB

자바는 메모리를 자동으로 정리해주는 managed 언어입니다.

프로그래머가 저수준의 메모리에 대한 제어권을 가질 수 없으며, 힙 메모리 할당과 해제는 이는 GC가 알아서 처리해주게 됩니다. 

 

# 무엇이 회수되는가

아래의 JVM 메모리 구조중 GC가 관여하는 공간은 Heap 메모리입니다.

스레드가 실행되며 지역변수를 저장하는 Stack과 정적인 Static 영역은 GC의 대상이 아닙니다.

 

 

# 어떻게 회수하는가. 약한 세대 가설

JVM의 GC는 약한 세대 가설(weak generational hypothesis)을 기반으로 설계되어있습니다.

• 대부분의 객체는 금방 접근 불가능한 상태가 된다.
• 오래된 객체가 젊은 객체를 참조하는 경우는 드물다.

이 가설을 적용시켜, GC는 모든 객체를 검사해가며 메모리를 해제하지 않습니다.

객체가 생성되면 GC의 Young영역에 할당시키고, 해당 영역이 가득차면 다음 영역으로 이동시켜 메모리를 정리합니다.

Young 영역에는 Survivor 영역이 존재합니다.

 

@ Young generation 영역

• 새롭게 생성된 객체 대부분이 이 영역에 위치합니다.
• Eden 영역에서 시작하지만, 만약 객체가 너무 커서 Young영역에 못들어간다면 바로 Old로 갑니다.
• 가득차면 minor gc가 발생합니다. 참조가 살아있는 객체만 남겨두고, 나머지는 다 삭제합니다.
• 살아있는 객체들 중 오래 사용하겠다고 판단된 객체들은 Tenured (또는 Old)영역으로 옮깁니다.

• Young -> [ Servivor1 <-> Servivor2 ] -> Tenured 이렇게 여러 단계를 거쳐 오래된 객체들이 복사, 삭제됩니다.
  Servivor를 사용하는 이유는 메모리 단편화 때문입니다. 객체를 할당 할 수 없을 때 번갈아가며 Servivor를 옮깁니다.

이렇게 2개의 Servivor 공간을 이용합니다. 적절하게 객체를 옮겨서 단편화를 해소합니다.

 

 

@ Tenured generation (Old) 영역

• Young 영역에서 참조가 살아있어 남아있는 객체들은 여기로 복사됩니다.
• 보통 객체의 생성과 삭제가 빠른 Young영역보다 메모리를 크게 할당합니다.
• 이렇게 세대를 나눠서 하는 GC방식의 가장 큰 단점은, 마지막 공간은 언젠가 가득찬다는 것입니다.
• 마지막 공간인 Tenured 영역이 가득차면 major gc (또는 full gc)가 발생합니다.

 

참조가 살아있는 객체를 임의로 지워버렸다가는 앱에 어떤 문제가 발생할 지 모릅니다.

그래서 마지막 Old 영역까지 메모리가 가득차버리면, GC는 Stop-the-world를 실행합니다.

쉽게말해 JVM에 있는 모든 스레드를 멈추고 빠르게 Old 영역의 객체를 스캔하여 필요없는 메모리를 해제합니다.

 

아무리 좋은 GC 알고리즘을 사용한다고 한들, 결국 Stop-the-world는 발생합니다.

특히 서버 컴퓨터의 경우 GC에 할당된 메모리가 커서 GC가 쌓이고 쌓이다가 한번에 정리하는 경우, 길게는 2~3분간 서버가 멈춰버릴 수 있습니다.

 

그래서 GC 메모리를 직접 튜닝하거나, 개선된 알고리즘을 가진 GC 구현체를 사용하는 것이 좋습니다.
실제로 GC 알고리즘이라 함은 Old 영역을 어떻게 처리할 것인가에 따라 구분짓게 됩니다.
Serial, Parallel, CMS[Concureent Mark & Sweep], G1[GarbageFirst]

https://d2.naver.com/helloworld/1329

 

 

# Old 영역에 있는 객체가 Young 영역을 참조하면 어떻게 되나요?

이러한 경우를 처리하기 위해 Old 영역에는 512바이트 단위(chunk)로 되어있는 card table이 존재합니다.

카드 테이블에는 Old 영역에 있는 객체가 Young 영역을 참조할 때 마다 정보가 표시됩니다.

 

minor gc, 즉 Young 영역을 GC할 때에는 이 카드 테이블만 추가로 확인해서 GC 여부를 식별합니다.

참고로 카드 테이블은 write barrier를 사용하여 관리합니다. 이는 Minor GC를 의 오버헤드를 줄이기 위해 사용하는데 궁금하면 해당 링크를 참조해주세요.

 

 

 

# TLAB (Thread-Local Allocation Buffer)

GC도 결국 JVM에게 스레드를 할당받아 동작하는 프로그램입니다.

성능을 높이기 위해서 GC에 여러 스레드를 할당하게 되면, 결국 스레드간 동기화 문제, 블로킹이 생기게 됩니다.

 

그래서 JVM은 Young에서 처음 사용되는 Eden영역을 여러 버퍼로 나누어, 스레드 별로 별도의 공간을 가지도록 만듭니다. 이를 Thread-Local 메모리라고 합니다.

각각의 스레드별로 별도의 메모리 공간을 가지기에 추가적인 메모리가 사용되지만, 스레드 별로 GC의 Eden 공간이 있어 객체를 생성하는 과정에서 동기화 문제를 생각 할 필요가 없기 때문에 성능적으로 큰 이득을 가져옵니다.

 

 

 

# 은탄환은 없다. GC 튜닝

모든 상황에 최적인 GC는 없습니다. 

어느 회사에 물어봐도, 아니면 아예 Oracle JVM을 만드는 엔지니어들에게 물어봐도 같은 말을 합니다.

WAS의 스레드 개수, 장비당 인스턴스 개수, GC 옵션, 서비스의 종류에 따라 최적의 GC 알고리즘과 메모리 튜닝은 달라집니다. 아무생각없이 막 튜닝을 하면 오히려 성능이 떨어질 수도 있습니다.

 

이는 공식이 있는 것이 아니기 때문에 JMX 같은 모니터링 도구로 확인하면서 직접 내 서비스에 맞는 GC 튜닝을 해야 합니다.