Garbage Collector 이야기 - 정의, 왜, 언제, 어떻게, 알고리즘, 종류

 

좋은 개발자는 "메모리 관리" 또한 잘 해야한다고 합니다.

그래서 Java를 공부하면서, 절대 빼먹을 수 없는 내용 중 하나가 가비지컬렉터입니다.

 

JVM (Java Virtual Machine)을 먼저 공부하고 오면 더 도움이 될 것 같습니다.

JVM에 대한 내용은 아래의 링크로 오시면 됩니다. 

 

https://mong-dev.tistory.com/38

JVM이야기 - 정의(+JRE, JDK), 구조

 

 

정의

---

Garbage Collector란?
동적으로 할당한 메모리 영역 중 사용하지 않는 영역을 탐지하여 해제하는 기능

 

 

GC는 왜 일어나는가?

---

어렵게 설명하기보다, 쉽게 실생활의 예를 통해 접근해보겠습니다.

 

예를 들어, 한 주방장이 있다고 가정하겠습니다. 이 주방장은 요리를 할 때마다 냉장고에서 음식을 꺼내옵니다. 가져온 음식은 테이블에 두고 요리를 합니다. 테이블이 재료들로 가득 차면 그 다음 요리를 진행할 수 없습니다. 그렇다면, 요리를 하면서 사용하지 않는 재료들은 그때그때 치워주는게 효율적일 것입니다.

 

기존에는 주방장이 치우는 것 까지 모두 하나하나 레서피에 모두 적어주었습니다. 예를 들어, 1. 생선을 꺼낸다. 2. 칼을 꺼낸다. 3. 생선을 자른다. 4. 칼을 치운다. 5. 생선을 치운다. 이런식으로 말입니다. 그러다 혹시라도 실수로 생선을 치우는 것을 적지 않는 경우도 발생하곤 했습니다. 하지만, 그에게 아주 똑똑한 조수가 나타났습니다. 주방장이 일일이 레서피에 무엇을 치워야할지 적어주지 않아도, 그 조수는 주방장이 무엇을 사용하는지 체크를 해놓고, 사용하지 않는 재료들을 알아서 잘 치워 두었습니다. 주방장은 훨씬 이 테이블을 효율적으로 사용할 수 있게 되었습니다.

 

본론으로 돌아와, 이 이야기를 다시 프로그래밍에 대입해보겠습니다. 레서피를 우리가 작성하는 코드라고 가정했을 때, 기존에 C언어에서는 처음 주방장이 레서피에 일일이 다 적어주듯이 사용하지 않는 메모리 영역에 대한 해제를 직접 코드로 작성해주어야만 했습니다. 하지만 아무리 신중한 사람이더라도, 깜빡 놓치고 남겨 두는 일이 생기기 마련입니다. 이때 발생하게 되는 것을 바로 Memory Leak(메모리 누수)라고 하는 것입니다. 

 

그런데, C언어와 달리 자바에게는 주방장이 안쓰는 칼을 알아서 치워주는 똑똑한 조수가 있습니다. 그것이 바로 Garbage Collector (가비지 컬렉터)입니다. Garbage는 '쓰레기'를 의미하는 단어입니다. 사용하지 않는 메모리 영역을 쓰레기라고 생각하면 훨씬 쉬울 것 같습니다.

 

이제 위에서 말한 동적으로 할당한 메모리 영역 중 사용하지 않는 영역을 탐지하여 해제하는 기능이라는 가비지 컬렉터의 개념의 의미가 조금 더 와닿으실 것 같습니다.

 

 

GC는 어디에서 발생하는가?

---

이 이야기를 하기 전에, 먼저 JVM의 전체적인 구조에 대한 이미지를 다시 한번 떠올려보시면 좋을 것 같습니다. 현재 글 위에 링크 걸어놓은 곳으로 이동하시면 관련 내용을 확인하실 수 있습니다. JVM에 대해 글을 작성하며 잠깐 언급한 적이 있었는데, JVM의 역할 중 하나는 메모리를 관리하는 것이고, 그 역할을 가비지 컬렉터가 담당하고 있다고 했습니다.

 

여기에서 가비지 컬렉터는 Execution Engine이라는 곳에 있습니다.

 

Execution Engine

 

이러한 GC(Garbage Collection)는 Heap 메모리에서 활동을 합니다. 그러니 Heap의 구조에 대해서도 당연히 보아야겠습니다.

 

Heap Area - Permanent Generation은 Java 8버전 부터 Native Method Stack에 편입

 

 

그림을 보면 메모리 구조를 크게 Young Generation, Old Generation이라는 2개로 나눈 것을 볼 수 있는데, 이것은 '약한 세대 가설(weak generational hypothesis)'라는 가설에 기반을 두고 있다고 합니다.

 

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

 

첫번째 가정을 보겠습니다. 대부분의 객체는 중괄호({})안에서 생성을 하고, 이 객체들은 괄호가 끝나는 시점에서 더이상 사용되지 않습니다. 특수한 경우에는 오래 사용할 수 있지만, 대부분의 경우 unreachable한 상태가 되어 GC의 대상이 됩니다.

 

두번째 가정을 보면, 일반적으로 객체는 순차적인 로직에 의해 생성하여 활용을 합니다. 이 과정에서 앞에 생성된 객체는 그 다음의 로직에서 사용된 이후 대부분 사용되지 않게 됩니다. 이런 특성으로 인해 더이상 참조되지 않는 객체에 대해 GC를 할 수 있게 된다는 것입니다.

 

GC라는 것은 결국 Heap Area에서 더이상 사용하지 않는 메모리를 제거한다는 것인데요, 전통적인 Heap Area는 위와 같은 구조를 가지고 있고, Eden, Survivor0, Survivor1, Old Generation으로 구분됩니다. (Permanent Generation은 Java 8버전 부터 Native Method Stack에 편입) 

 

이렇게 GC는 각 영역을 활용하여 최적의 메모리를 운영하게 됩니다. 

 

 

GC는 어떻게 동작하는가?

---

1. 맨처음 객체가 생성되면 Eden 영역에 생성됩니다.

 

2. Eden영역이 차면, 미사용 객체의 제거와 함께 아직 사용되고 있는 객체는 Survivor0, Survivor1 영역으로 이동시킵니다. 이것을 Minor GC가 발생한다고 하는 것입니다. (단, 객체의 크기가 Survivor 영역의 크기보다 클 경우에는 바로 Old Generation으로 이동합니다.)

 

Minor GC

 

3. 참고로 Survivor0와 Survivor1 영역은 둘 중 한곳에만 객체가 존재하게끔 운영되며, 다른 한 곳은 비어져 있어야합니다. 보통 From, To로 구분을 하며, 객체가 존재하는 Survivor영역(From)이 가득 차면 다른 Survivor 영역(To)로 보내고, 기존의 From을 비우는 작업을 진행합니다.

 

이해가 어려우실 수도 있으니 아주 간단하게 예를 들어보겠습니다. (이해를 돕기 위한 예입니다)

 

eden영역이 꽉차고, Survivor0으로 살아남은 객체가 이동함을 반복하다가, Survivor0이 꽉 차게 되었을때, 여기서도 GC가 일어날 것이고, 거기서 살아남은 객체들은 이번에는 Survivor1으로 이동할 것입니다. 이동하면서 score값이 증가하게됩니다. 단순하게 생각해보자면, 예를들어 Minor GC를 통해 살아남은 객체의 Survivor0에서의 스코어가 0이라고 가정했을 때, Survivor1으로 이동하면서 그 스코어가 1로 증가하게 됩니다. 위에서 언급했듯이, Minor GC가 발생하고 살아남은 객체들은 Survivor의 두 영역중에서 이미 사용중인 곳으로 쌓이게 될 것입니다. 한 곳은 비워두어야 하기 때문이죠. 그럼 Minor GC를 통해 새롭게 Survivor1에 들어오는 영역은 스코어 값이 1이 아닌 0일 것입니다. (스코어가 높을수록 진하게 표시했습니다.) 그럼 한 Survivor영역안에 score값이 다른 객체들이 혼재하고 있겠습니다.

 

Survivor1의 모습

 

위 과정(1~3)을 반복하다보면, Survivor영역에서 계속 살아남은 객체들에게 일정 score가 누적이 되어 기준치 이상이 되면 Old Generation 영역으로 이동을 하게 됩니다. 이 과정을 Promotion이라고 합니다. 

 

promotion

 

5. Old Generation 영역에서 살아남았던 객체들이 일정 수준 쌓이게 되면, 미사용으로 판단된 객체들을 제거해주는 Major GC가 발생합니다. 이 과정에서 STW가 발생합니다. 

 

여기서 STW가 무엇인지 잠시 언급하고 넘어가겠습니다.

 

STW란 Stop The World의 약자로, GC를 수행하기 위해 JVM이 멈추는 현상을 의미합니다. GC가 작동하는 동안 GC관련 Thread를 제외한 모든 Thread가 멈추게 됩니다. 이렇듯 모든 쓰레드가 정지되기 때문에 더 이상 작업이 실행되지 않고, 성능이 저하됩니다. 그래서 적절한 빈도의 GC 가 실행되도록 하여, Stop-The-World 시간을 줄여 쓰레드가 정지되는 시간을 줄이는 것이 중요하며, 일반적으로 '튜닝'이라는 것은 이 시간을 최소화하는 것을 의미합니다.

 

여기까지 GC가 어떻게 동작하는지 알아보았습니다. GC에는 여러가지 종류가 있습니다. 그 종류를 알아보기 전, 각각의 GC는 다른 알고리즘을 사용하고 있는데, 그것에 대해 먼저 알아보겠습니다.

 

 

GC 알고리즘

---

GC는 기본적으로 Garbage 대상을 식별하고 그 대상을 메모리에서 제거하는 것입니다. 이 기본 동작과 관련된 알고리즘은 아래와 같이 있습니다.

 

Reference Counting Algorithm

- 각 개체마다 Reference Count를 관리하며, 이 카운트가 0이 되면 GC를 수행

- 카운트가 0이 되면 바로 메모리에서 제거

- 순환 참조 구조에서 Reference Count가 0이 되지 않는 문제가 발생하여 Memory Leak이 발생

 

Mark-and-Sweep Algorithm

- Reference Counting Algorithm의 단점을 극복하기 위해 나온 알고리즘

- RSet(Root Set)에서 Reference를 추적하여 참조 상황을 파악

- Mark 단계에서 Garbage대상이 아닌 객체를 마킹하고, Sweep 단계에서 마킹되지 않은 객체를 지움

- 위 단계를 마친 후 마킹 정보를 초기화

- 이 방식은 GC가 동작하고 있을 경우, Mark 작업과 어플리케이션 Thread의 충돌을 방지하기 위해 Heap의 사용이 제한 됨

- Compaction 작업이 없어 그 사이사이에 비어있는 공간을 재사용하려고 하면, 다시 사용할려고 하는 영역보다 객체의 크기가 더 클 경우 (즉, 비어있는 공간이 충분하지 않을 경우), Out of Memory가 발생할 수 있음

 

Mark-and-Compact Algorithm

- 기존의 mark and sweep 알고리즘에서 발생하는 점유 메모리 분산(fragmentation)을 해결하기 위해 나온 알고리즘

- Sweep 작업 이후에 Compact 작업이 추가되어 흩어져 있는 메모리를 모아주는 작업을 진행

- Compact작업으로 메모리 효율을 높일 수 있음

- 하지만 Compact작업과 그 이후 Reference를 업데이트 하는 작업으로 인해 오버헤드(Overhead)가 발생할 수 있음

 

그 외에도 Copying Algorithm, Concurrent Mark-Sweep, Generational Algorithm 이런 것들이 있는데, 이 정도로만 작성하도록 하겠습니다.

 

그럼 이제, 이러한 알고리즘을 사용하는 GC의 종류에 대해 알아보겠습니다.

 

 

GC의 종류

---

Serial GC

- 가장 오래된 GC

- 하나의 CPU로 Young Generation과 Old Generation을 연속적으로 처리하는 방식

- Mark-and-Compact 알고리즘을 사용 (GC가 수행될 때 STW가 발생)

 

Parallel GC

- 자바 7~8 버전에서 Default로 설정되어 있는 GC

- 다른 CPU가 GC의 진행시간 동안 대기 상태로 남아 있는 것을 최소화하는 것이 목표

- GC작업을 병렬로 처리하여 STW 시간이 비교적 짧음

 

Parallel Compacting GC

Parallel GC에서 Old Generation의 처리 알고리즘을 변경함

 

Concurrent Mark-Sweep(CMS) GC

- 어플리케이션의 쓰레드와 GC쓰레드가 동시에 실행되어 STW를 최소화

- 그전에는 GC쓰레드가 실행되면, 어플리케이션의 쓰레드가 멈추었음

- Parallel GC와 가장 큰 차이점은 Compaction 작업 유무로 구분이 되는 것

 

여기서 부터는 전통적인 메모리 구조 형태라기 보다는 좀더 파편화 시켜서 일정 크기의 Region을 잘게 쪼개서 더 효율적으로 사용하고자 하였습니다.

 

Garbage First(G1) GC

- 큰 메모리에서 사용하기 적합한 GC

- 대규모 Heap 사이즈에서 짧은 GC 시간을 보장하는데(STW를 최소화) 목적을 둠

- 전체 Heap 영역을 Region이라는 영역으로 분할하여 상황에 따라 역할이 동적으로 부여 됨

 

Z GC

- ZPage라는 영역을 사용

- G1 GC의 Region은 크기가 고정인데 비해 Zpage는 2mb 배수로 동적으로 운영

- 정지 시간이 최대 10ms를 초과하지않는 것을 목적으로 운영

- Heap의 크기가 증가하더라도 정지 시간이 증가하지 않는 것이 특징