F008 - Garbage Collector

✍️ 저번 시간에 공부했던 JVM 내용과 연결되는 이유로 Garbage Collector(이하 GC)에 대해 공부해보려고 한다.

Reference Type 과 Heap Memory를 공부하면서 Heap Memory 내에 존재하는 객체를 참조하는 곳이 없을 때 GC가 이를 처리해준다는 것은 조금이나마 이해했다. 그렇다면 어떤 시점에, 어떤 방법으로 GC는 메모리를 정리해주는걸까?

이번 시간을 통해 알아보자!

---

Un-Managed Language, Managed Language

많은 프로그래밍 언어들은 Mangaed Language, Un-Managed Language 로 나뉘어 구분될 수 있다. 이 둘의 의미는 무엇을 뜻하는걸까? 개발자가 직접 메모리를 관여해야 한다면 Un-Managed Language, 관여하지 않아도 알아서 메모리가 최적화가 진행된다면 Managed Language 라고 한다.

Un-Managed Language

C, Cpp, Assembly 등이 여기에 속한다. 해당 영역의 언어들은 개발자가 직접 메모리나 CPU에 접근해 애플리케이션의 최적화를 기대 할 수 있다. 하지만 예상치 못하게 메모리 누수가 발생하는 등의 문제 발견 시, 해당 문제를 해결하기가 어렵다.

Managed Language

Java, Ruby, PHP 등 인터프리터, 컴파일러 혹은 런타임 환경에서 동작하는 언어들이 해당 영역에 속한다. 해당 언어들은 개발자가 직접 메모리에 접근할 권한이 없거나 극히 제한적이다. 떄문에 GC 등을 통해 자체적으로 메모리를 관리한다. 다만 Managed Language에 비해 메모리 최적화 속도가 느리고 사용되는 방식에 따라 다양한 단점이 존재한다.

---

Garbage Collector

지난 시간을 통해 Reference Type은 Heap 메모리에 값이 저장된다는 것을 배웠다. 기존 Java에서는 GC 작업이 개발자가 관여하지 않도록 개발되었는데, JDK 1.2부터 조금이나마 관여 할 수 있도록 수정되었다. 이를 통해 java.lang.ref 패키지가 제공되어 Strong, Week, Soft, Phantom Reference 클래스를 이용하여 개발자가 메모리 최적화에 일정 부분 관여 할 수 있게 되었다.

이러한 GC는 두 가지 가절을 기준으로 만들어졌다.

• 대부분의 객체는 금방 접근 불가능한 상태(Un-Reachable)가 된다.
• 오래된 객체에서 새로운 객체로의 참조는 아주 드물게 일어난다.

그렇다면 GC는 Heap 메모리에서 참조하지 않는 값을 찾아 제거하는데 어떻게 지워야 할 값인지 아닌지 구분하는걸까? 만약 GC가 이를 구분한다면 Heap 메모리는 GC가 값을 잘 구분 할 수 있도록 세부적으로 영역이 나뉘어져 있지 않을까?

Reachablilty

기본적으로 Heap 메모리에 할당된 객체는 Reachablilty 개념을 통해 해당 객체가 참조되었는지 되지 않았는지 구분된다.

✔️  Reachable 유효한 참조가 있는 객체

✔️  Un-Reachable 어떤 곳에서도 참조하지 않는 객체, Garbage Collector 대상

✔️  Root Set 객체가 참조하고 있는 최초의 객체를 의미한다. Root Set을 참조하고 있는 객체들의 참조가 존재하지 않는다면 해당 객체들과 Root Set 객체는 Un-Reachable 로 간주되어 GC에 의해 정리된다. (21/05/17 hpotter1993님, 피드백 감사합니다!)

Garbage Collector 과정

(좌측은 JDK 1.7 이전, 우츤은 JDK 8 이후 / Perm 영역이 MetaSpace로 변경되어 OS에서 자체적으로 메모리를 할당한다.)

1️⃣  Minor Garbage Collector Young Generetion 에서 발생한다.

2️⃣  Major Garbage Collector Old Generetion, Perm 에서 발생한다.

3️⃣  Full Garbage Collector 모든 영역을 대상으로 발생한다. 해당 종류의 GC가 발생하면 JVM이 멈추는데 이를 Stop-the-World 라고 한다.

System.gc()

Runs the garbage collector. Calling the gc method suggests that the Java Virtual Machine expend effort toward recycling unused objects in order to make the memory they currently occupy available for quick reuse. When control returns from the method call, the Java Virtual Machine has made a best effort to reclaim space from all discarded objects.

System.gc() 메소드를 사용하면 애플리케이션 실행 중 강제적으로 GC를 수행하게 된다. 하지만 모든 스레드가 멈추기 때문에 코드 중간에 해당 메소드를 호출하는 행위는 하지 않는 것이 좋다.

public class GcTest {
    public static void main(String[] args) {
        long start = System.nanoTime();
        System.gc();
        long end = System.nanoTime();

        System.out.println(start - end + "ns");
    }
}

Young Generation

새롭게 생성된 객체가 처음 머무르는 영역이다. Minor GC가 관여하는 영역이며, HotSpot JVM에서는 빠른 메모리 할당을 위해 두 가지 기술을 사용한다. bump-the-pointer 와 TLABs 기술이다.

🔎 Eden new 생성자로 새롭게 초기화되거나 생성된 객체들이 가장 처음 머무르는 영역이다. 해당 영역이 모두 차면 GC가 Un-Reachable 한 객체를 찾아 제거하고 살아남은 Reachable 객체를 Survivor 1 영역으로 이동시킨다.

🔎 Survivor 1/2 Eden 영역에서 살아남은 Reachable 객체들이 Survivor 1 영역에 할당되고, 해당 영역이 꽉 차면 다시 GC가 Un-Reachable 한 객체를 찾아 제거한 후, Reachable 객체를 Survivor 2 영역으로 이동시키고 Survivor 1 영역을 비운다. Survivor 2 영역이 차게 되면 다시 위의 과정을 거쳐 Survivor 1에 객체를 옮기고 Survivor 2 영역을 비운다. 즉, 두 영역 중 한 영역은 비워져 있어야 한다. 예외적으로 해당 영역을 거치지 않고 Old 영역으로 다이렉트로 넘어가는 경우가 있는데, 이는 객체의 크기가 Survivor 크기보다 클 경우에 해당된다.

Old Generetion

Young 영역에서 살아남은 Reachable 객체로 Full GC, Major GC 가 일어나지 않는 이상 메모리에서 사라지지 않는다. 이 때, 처리하는 방식은 JDK 7을 기준으로 5가지가 존재한다.

---

GC의 종류

💥 Serial GC (-XX:+UseSerialGC)

Young 과 Old 영역이 연속적으로 처리되며 해당 GC가 수행될 때 JVM의 수행을 멈추고 GC를 수행하는데, 이를 Sun에서는 Stop-the World라고 표현한다. 멀티 스레드 환경에서는 사용 할 수 없는 싱글 스레드 시스템에 적합한 GC로, 모든 종류의 GC를 수행한다. Young 영역에서는 Serial 알고리즘이 사용되고, Old 영역에서는 Serial Mark-Sweep-Compact 알고리즘이 사용된다.

➡️ Mark-Sweep-Compact 알고리즘 Old 영역에 살아있는 객체를 식별(Mark)하고 Heap 메모리의 앞부분부터 확인해서 Reachable한 객체만 남긴다.(Sweep) 마지막으로 Reachable 객체들이 연속으로 Heap 메모리의 가장 앞에서 부터 쌓이도록 한 다음 객체가 존재하는 공간과 존재하지 않는 공간을 나누어 수행한다.(Compact)

💥 Parallel GC (-XX:+UseParallelGC)

Parallel GC는 기본적으로 Old 영역에서는 Serial GC와 동일한 알고리즘으로 동작하지만 Young 영역에서는 병렬로 처리해 CPU를 사용해 GC의 부하를 줄여 CPU의 대기 상태를 최소화하여 애플리케이션 성을을 끌어 올릴 수 있다. 보통 ThroughPut GC 라고도 부른다.

💥 Parallel Old GC

Young 영역에서는 병렬적으로 Garbage를 처리하며, Old 영역에서는 Mark-Summary-Compaction 단계를 사용하여 처리한다. Parallel GC의 Mark-Sweep-Compact 알고리즘에서 Sweep 부분과 Summary 부분이 약간 다른데, Summary 단계에서 GC를 수행한 영역에서 한번 더 Reachable 객체를 한인한다는 점에서 조금 더 복잡하다.

💥 CMS GC (-XX:+UseConcMarkSweepGC)

기존의 다른 GC 방식보다 훨씬 복잡한데, 총 3딘계의 Mark 단계를 거친다. 1) Init Mark 단계에서는 클래스 로더에서 가까운 Reachable 객체를 확인하고, 2)해당 객체들을 Current Mark 단계에서 Root Set 객체를 따라 확인한다. 이 단계에서는 다른 스레드가 실행 중 일 때 동시에 진행된다. 3) Remark 단계에서는 이전 단계에서 새로 생성되거나 참조가 끊긴 객체를 확인하고, 이를 Cuncurrent Sweep 단계로 넘겨 메모리를 최적화한다. 이러한 단계로 진행되기 때문에 Stop-the-World 시간이 짧아져 실행 중인 애플리케이션의 응답 속도가 중요할 때 사용된다. 그래서 CMS GC를 Low Latency GC라고 부른다. 하지만 이런 이점에도 불구하고 CMS GC는 Compaction 과정이 존재하지 않기 때문에 메모리 단편화라는 문제가 발생하며, 다른 GC 방식보다 더 많은 메모리와 CPU를 사용한다.

💥 G1 (Garbage First) GC

큰 메모리를 가진 멀티 프로세서 시스템에 사용하기 위한 목적으로 개발된 GC로, 병렬 스레드 및 동시 스레드 모두 사용하며, Java 프로그램이 실행되는 동안 동시 스레드를 사용하여 살아있는 Reachable 객체를 탐색하고, 병렬 스레드를 이용해 해당 객체를 빠르게 복사해서 Stop-the-World 시간을 단축하면서 별도의 설정을 하지 않아도 가능한 한 처리량을 확보하는 것을 목표로 한다. JDK 7 부터 정식 지원하며 JDK 9 부터 Default GC로 사용된다. 다만, Stop-the-World의 시간이 단축되었다고 해서 G1 GC가 실시간(Real Time) GC는 아니다.

G1 GC는 CMS GC와 비슷하게 작동되지만, G1 GC는 전역 표시 단계를 거처 Heap 전체에 객체 수명을 결정한다. 이 때, 표시 단계가 완료되면 G1 GC는 어떤 영역이 비워져야 하는지 알게 되고, 이를 중점적으로 빠르게 메모리를 정리한다.

---

🤦‍♂️ Garbage Collector를 정리하는데 정말 오래 시간이 걸린 것 같다.
무엇보다 여러 블로그를 검색해서 읽어봐도 이해되지 않는 부분이 너무 많아서 계속 반복해서 다시 생각하는 방식으로 공부하다 보니 그런 것 같다.

코어한 내용에 접근하면 할 수록 CS의 중요성이 크게 와닿는다. 왜냐하면 일단 CS 지식이 없으니 쉽게 이해가 되지 않는다.
그래도 많은 분들이 쉽게 설명해주신 부분이 있어 그걸 통해 하나씩 깨우치고 있지만 더 깊게 파고 싶어 원문을 찾아보면 도대체 무슨 말인지 알 수 없는 것들이 많다.

그래도 내가 또 하나 더 알게 되었ㄷ는 점에서 뿌듯하고 재밌다!
이번 내용은 Java 프로그래밍의 근간이 되는 내용이니까 꾸준히 상기할 수 있도록 해야겠다.
(그리고 영어 원문도 읽고 이해 할 수 있도록 노력해야겠다!)

---

참고 문서

Understanding Garbage Collectors

Getting Started with the G1 Garbage Collector

NAVER D2

Tunning

JVM 메모리 구조와 GC