🧹Java는 Java가 청소해줘!

C/C++의 경우 프로그래밍을 할 때 메모리 누수를 막기 위해 사용하지 않는 객체의 메모리를 개발자가 직접 해제 해줘야 했다. 하지만 Java에서는 그 역할을 다른 누가 해준다. 바로 Garbage Collection , GC이다.
GC 는 JVM 상에서 더 이상 사용되지 않는 데이터가 할당되어있는 메모리를 해제시켜주는 장치이다. JVM에서 자동으로 동작하기 때문에 Java를 사용할 때 특별한 경우가 아니면 메모리 관리를 개발자가 직접 해줄 필요가 없다.(System.gc()로 메모리를 명시적으로 해제할 경우 시스템 성능에 매우 큰 영향을 끼치므로 사용하지 않도록 하자)

stop-the-world

듣자하니 GC는 개발자의 관리 범위를 줄여주고 좀더 로직에 집중할 수 있게 도와주는 것 같다. 그렇다면 이 좋은 GC를 많이 사용하면 할수록 좋을까?
예상했지만 그렇지 않다. GC의 작동은 'stop-the-world'라는 용어로 설명된다.
stop-the-world란, GC을 실행하기 위해 JVM이 애플리케이션 실행을 멈추는 것이다. stop-the-world가 발생하면 GC를 실행하는 쓰레드를 제외한 나머지 쓰레드는 모두 작업을 멈춘다. GC 작업을 완료한 이후에야 중단했던 작업을 다시 시작한다.
즉, GC를 사용하는 개발자는 무작정 GC를 사용하는 것이 아니라 stop-the-world 시간을 줄이는 방향으로 GC를 사용해야하고 GC튜닝이란 이 시간을 줄이는 것을 이야기한다.

🔎 GC 동작 방식

mark-sweep-compact

그렇다면 GC는 어떻게 참조되지 않는 메모리를 찾을까? 가장 원초적인 방식이 'mark-sweep-compact' 방식이다. mark-sweep-compact는 이름 그대로 mark, sweep, compact 3단계로 이뤄지는 방식이다.

• mark : 참조되는 메모리, 참조되지 않는 메모리를 식별한다.
• sweep : Heap의 앞부분부터 참조되는 메모리만 남기고 나머지는 삭제한다.
• compact : 각 객체들이 연속되게 쌓이도록 Heap의 가장 앞 부분부터 채워서 객체가 존재하는 부분과 객체가 없는 부분으로 나눈다.
  

Weak Generational Hypothesis

하지만 mark-sweep-compact 방식은 시간도 오래 걸리고 비효율적이다. 아래의 그래프를 보면 Y축은 할당된 바이트의 수이고 X축은 바이트가 할당될 때의 시간이다. 그래프 상에서 시간이 지날수록 적은 객체만 살아남는다는 사실을 확인할 수 있다.
즉, 객체 마다 유지된 시간에 따라 참조가 해제될 가능성이 달리지니 이 특성을 이용하여 더 효율적인 GC 관리가 가능할 것이다.

위에서 확인한 그래프를 토대로 만들어진 가설이 Weak Generational Hypothesis이다. 해당 가설은 다음과 같은 가설을 포함하고 있다.

• 대부분의 객체는 금방 접근 불가능 상태(unreachable)가 된다.
• 오래된 객체에서 젊은 객체로의 참조는 아주 적게 존재한다.

GC의 효율성을 위한 Heap 구성

Weak Generational Hypothesis의 장점을 최대한 살리기 위해서 HotSpot VM에서는 크게 2개로 물리적 공간을 나누었다. 둘로 나눈 공간이 Heap의 Young 영역과 Old 영역이다.

• Young 영역(Yong Generation 영역): 새롭게 생성한 객체의 대부분이 여기에 위치한다. 대부분의 객체가 금방 접근 불가능 상태가 되기 때문에 매우 많은 객체가 Young 영역에 생성되었다가 사라진다. 이 영역에서 객체가 사라질때 Minor GC가 발생한다고 말한다.
• Old 영역(Old Generation 영역): Young 영역에서 age threshold(문지방)까지 살아남은 객체가 여기로 복사된다. 대부분 Young 영역보다 크게 할당하며, 크기가 큰 만큼 Young 영역보다 GC는 적게 발생한다. 이 영역에서 객체가 사라질 때 Major GC(혹은 Full GC)가 발생한다고 말한다.

Minor GC 과정

Minor GC가 수행되는 Young 영역은 다음과 같이 3개의 영역으로 나뉜다.

• Eden 영역
• Survivor 영역(2개)
  

기본적으로 데이터가 가득차는 시점이 GC 수행의 시점이 된다.
Minor GC의 수행 절차는 다음과 같다

[ Minor GC ]

• 새로 생성한 대부분의 객체는 Eden 영역에 위치한다.
• Eden 영역에서 GC가 한 번 발생한 후 살아남은 객체는 Survivor 영역 중 하나로 이동된다.
• Eden 영역에서 GC가 발생하면 이미 살아남은 객체가 존재하는 Survivor 영역으로 객체가 계속 쌓인다.
• 하나의 Survivor 영역이 가득 차게 되면 가득찬 Survivor 안에서 GC를 수행하고, 살아남은 객체를 다른 Survivor 영역으로 이동한다. 그리고 가득 찬 Survivor 영역은 아무 데이터도 없는 상태로 된다.
• 이 과정을 반복하다가 age threshold(문지방) 이상으로 살아남아 있는 객체는 Old 영역으로 이동하게 된다.

위 그림에서도 확인할 수 있지만 Minor GC 과정에서 Survivor 영역 중 하나는 반드시 비어 있는 상태로 남아 있어야 한다. 만약 두 Survivor 영역에 모두 데이터가 존재하거나, 두 영역 모두 사용량이 0이라면 무언가 잘못되고 있다고 생각해야 한다.

+ 더 빠른 메모리 할당을 위한 추가 방법

HotSpot VM에서는 보다 빠른 메모리 할당을 위해서 bump-the-pointer와 TLABs(Thread-Local Allocation Buffers) 라는 기술을 추가로 사용한다.

bump-the-pointer
bump-the-pointer는 Eden 영역에 할당된 마지막 객체를 추적한다. 마지막 객체는 Eden 영역의 맨 위(top)에 있다. 그리고 그 다음에 생성되는 객체가 있으면, 해당 객체의 크기가 Eden 영역에 넣기 적당한지만 확인한다. 만약 해당 객체의 크기가 적당하다고 판정되면 Eden 영역에 넣게 되고, 새로 생성된 객체가 맨 위에 있게 된다.
따라서, 새로운 객체를 생성할 때 마지막에 추가된 객체만 점검하면 되므로 매우 빠르게 메모리 할당이 이루어진다.

TLABs(Thread-Local Allocation Buffers)
만약 bump-the-pointer를 멀티 스레드 환경에서 사용한다면 문제가 발생한다. 여러 스레드에서 사용하는 객체를 Thread-Safe하게 Eden 영역에 저장하고 추적하려면 락(lock)이 발생할 수 밖에 없고, lock-contention 때문에 성능은 매우 떨어지게 될 것이다.
이를 해결하기 위해 TLAB는 스레드가 각각의 몫에 해당하는 Eden 영역의 작은 덩어리를 가질 수 있도록 하여 자기가 갖고 있는 덩어리에만 접근할 수 있게 분리한다. TLAB를 사용하면 bump-the-pointer를 사용하더라도 락 없이 메모리 할당이 가능하다.

Major GC 종류 및 과정

Old 영역은 기본적으로 데이터가 가득 차면 GC를 실행한다. 이때 어떤 GC 알고리즘을 사용하냐에 따라 과정이 달리지는데 JDK 7 기준으로 아래와 같이 5가지 방식이 존재한다.

Serial GC

앞서 살펴본 mark-sweep-compact 알고리즘을 사용하는 GC이다. JDK 5,6 에서 사용되는 GC로 Minor GC와 Major GC 모두 싱글스레드로 수행하기 때문에 GC가 진행되는 시간(Stop-The-World)이 다른 GC에 비해 오래 걸린다. 운영 서버에서 사용하면 안되는 방식이다.

Parallel GC

Serial GC와 동일하게 mark-sweep-compact 알고리즘을 사용하지만, Young 영역에서 발생하는 Minor GC 수행시 멀티 스레드를 사용한다. 따라서 Serial GC보다 빠르게 객체를 처리할 수 있다. 하지만 사용하는 장비의 CPU가 단일 코어인 경우 Parallel GC로 설정해도 Serial GC로 수행된다.

Parallel Old GC(Parallel Compacting GC)

JDK 5 update 6부터 제공한 GC 방식으로 Parallel GC와 Young 영역의 동작 방식은 동일하다. 하지만 Old 영역에서 발생하는 Full GC도 병렬로 처리하며, Old 영역에서 발생하는 GC를 처리할때 Mark-Summary-Compaction 알고리즘을 이용한다. Summary 단계는 앞서 GC를 수행한 영역에 대해서 별도로 살아 있는 객체를 식별한다는 점에서 Mark-Sweep-Compaction 알고리즘의 Sweep 단계와 다르며, 약간 더 복잡한 단계를 거친다.

Concurrent Mark & Sweep GC(이하 CMS)

CMS GC는 Old 영역에서 발생하는 Full GC의 수행시간을 최소한으로 하는데 초점을 둔 GC 방식이다. 즉 Stop-The-World의 시간을 최소화 한다. 작동 방식은 다음과 같다

• Initial Mark : 클래스 로더에서 가장 가까운 객체 중 살아 있는 객체만 찾는다.
• Concurrent Mark(STW 발생X) : Initial 과정에서 찾은 객체에서 참조하고 있는 객체를 따라가면서 확인한다. 해당 과정은 다른 스레드가 진행하는 과정에서 동시에 진행된다.
• Remark : Concurrent 과정에서 새로 추가되거나 참조가 끊긴 객체를 확인한다.
• Concurrent Sweep(STW 발생X) : 쓰레기를 정리하는 작업을 실행한다. 해당 과정도 다른 스레드가 진행하는 과정에서 동시에 진행된다.

CMS GC방식은 위에서 확인한 것처럼 Initial Mark 과정과 Remark 과정만 stop-the-world가 발생하므로 stop-the-world 시간이 매우 짧다. 모든 애플리케이션의 응답 속도가 매우 중요할 때 CMS GC를 사용하며, Low Latency GC라고도 부른다.

시간은 매우 짧지만 CMS GC에도 단점이 존재한다.

1. 다른 GC 방식보다 메모리와 CPU를 더 많이 사용한다.
2. Compaction 단계가 기본적으로 제공되지 않는다.
   즉, 메모리 단편화에 대한 우려가 있다. 만약 연속적인 메모리 할당이 불가능할 정도로 메모리 단편화가 진행되었다면 Compaction 작업을 수행해야 하는데, 해당 작업은 다른 GC에서의 Compaction 작업에 비해 stop-the-world 시간이 길다. 따라서 CMS GC를 사용할때는 Compaction 작업이 얼마나 일어나는지 파악한 후 사용하는 것이 좋다.

G1(Garbage First) GC

기존 GC알고리즘 들로는 큰 메모리에서 좋은 성능을 내기 힘들었기 때문에 이를 개선하고자 등장한 알고리즘이다. G1 GC 알고리즘은 기존의 정형화된 Heap 구조가 아닌 Heap을 Region이라는 논리적인 단위로 나눠서 관리하며 각각의 Region에 특정 역할(Eden,Survivor,Old,Humonogous)을 동적으로 부여한다.

JVM Heap은 2048개의 Region으로 나뉠 수 있으며, 각 Region의 크기는 1MB ~ 32MB 사이로 지정된다.
위 역할 중 Humonogous는 Region 크기의 50%를 초과하는 객체가 저장되는 공간이며, 이 공간에서는 GC가 효율적으로 일어나지 않는 영역이다.

G1 GC에서 Young GC 를 수행할 때는 stop-the-world 현상이 발생하며, stop-the-world 시간을 최대한 줄이기 위해 멀티스레드로 GC를 수행한다. Young GC는 각 Region 중 GC대상 객체가 가장 많은 Region(Eden 또는 Survivor 역할)에서 수행 되며, 이 Region 에서 살아남은 객체를 다른 Region(Survivor 역할) 으로 옮긴 후, 비워진 Region을 사용가능한 Region으로 돌리는 형태 로 동작한다.

G1 GC는 CMS GC와 다르게 Compaction 단계를 진행하여 메모리 단편화 문제를 없앴다. 또한 stop-the-world 시간을 예측할 수 있다.

Next..

다음 글에서는 GC가 판별하는 객체에 대해 다뤄보겠다.

참고 자료

Java Garbage Collection _ NAVER D2
JVM에 관하여 - Part 4, Garbage Collection 기초 _ Tecoble
Java Platform, Standard Edition HotSpot Virtual Machine Garbage Collection Tuning Guide _ Oracle Java 8